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

From: Ghyslain Pelletier <[email-masked]>
Date: Thu, 01 Apr 2004 16:00:59 +0200

Hi all,

I have looked through the specs, as well as through both the current and
old mail discussions on this topic.

My take is that although it may seem as if there was an agreement in
older mail list discussions regarding the use of a "slope" and how to
"learn a slope", I can not find that this resulted in any normative text
anywhere in 3095; therefore I tend to agree with Kristofer as to that
these concepts do not exist in 3095.

Also, I wonder why this additional "learned slope" would help at all. If
TS_STRIDE represents the expected increase in the timestamp value
between two RTP packets with consecutive sequence numbers, what is this
slope trying to correct? Does this not mean that the value of TS_STRIDE
needs to be updated? In the case of video that was discussed, it seem to
make more sense to update TS_STRIDE (or TS_OFFSET as Kristofer
suggested), as for both U/O-mode and R-mode (2 ACKs, min 1 RTT) this
will be faster than to update the "slope" based on 2 packets in U/O-mode
or the reception of 2 ACKs in R-mode.

Also, regarding the following text in 5.5.1.2.

   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.

This, in my opinion, is informative text - it does not specify anything.
Furthermore, I cannot find any normative equivalent or any normative
follow-up to this anywhere in 3095.

Going with what is actually written in the specs, I therefore tend to
agree in general with Kristofer's opinions on this matter.

/Ghyslain

[email-masked] wrote:
> 
> > 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
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

-- 
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
[email-masked]
http://www.ericsson.com

I have a new mail address: [email-masked]
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

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

---

From: [email-masked]
Date: Thu, 1 Apr 2004 15:23:22 -0500

> You're taking that comment out of its context. What I 
> intended all along with that was that "in the spec, as it 
> is written today, there cannot be room for a 
> slope". Sorry if I confused you. The same goes for the next comment.

That's fine. At least you agree that slope is not the same thing
as TS_STRIDE. So it is not a valid argument for your belief that
"there cannot be room for a slope". OK?

BR,
Zhigang

---

From: [email-masked]
Date: Thu, 1 Apr 2004 16:20:46 -0500

I agree with Kamal.

It's clear that TS_STRIDE means what it means in section 4.5.3.
TS_STRIDE is the scaling factor. Period. This is also reinforced
in many other sections.

On the other hand, I do agree that the terminology section could 
have been written better. But as Kamal commented, there is no real 
contradiction. Still, I'd like to propose the following text in 
the implementation I-D to clarify the issue:

-----------------
As it is described in section 4.5.3 and other places in RFC
3095, TS_STRIDE is the factor by which an RTP Timestamp is
downscaled before compression. Obviously, it cannot be 0 (zero).

The wording of TS_STRIDE definition in section 2 may be
incorrectly interpreted as TS_STRIDE is always equal to
the increase in TS value between two RTP packets with
consecutive sequence number. This is not the intent of the
specification. It is the compressor that decides whether TS 
scaling should be used and if yes, what is the best value of 
TS_STRIDE. How this is done is an implementation issue. 
However, an implementation must follow section 4.5.3, 4.5.6 
and 5.7 on how to initialize, encode, and synchronize 
TS_STRIDE between the compressor and decompressor.

Note: TS_STRIDE is not the same as slope described in section 
5.5.1.2 and 5.7.
--------------------

I think the above text addresses Kristofer's concern. Comments?

BR,
Zhigang

> -----Original Message-----
> From: ext kamal deep singh [mailto:[email-masked]]
> Sent: 01 April, 2004 04:14 AM
> To: Kristofer Sandlund; Liu Zhigang.C (Nokia-NRC/Dallas)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp
> field
> 
> 
> 
> hi Kristofer,
> 
> We can still avoid the confusion given by 2.0 if we consider that
> TS_STRIDE is "expected" increase and not everytime increase.
> 
> > That is a contradiction of 2.0:
> >
> >     Timestamp stride
> >
> >        The timestamp stride (TS_STRIDE) is the expected 
> increase in the
> >        timestamp value between two RTP packets with 
> consecutive sequence
> >        numbers.
> >
> > 4.5.3 talks about stride as the "frame delta" and 2.0 as the "packet
> delta".
> > So yes, if 4.5.3 "overrides" 2.0 then you're right that the 
> stride cannot
> be 0,
> > and then I can see why you think I'm silly to say we must 
> define modulus
> 0. But
> > if 2.0 overriders 4.5.3, then I still think I'm right.
> > That's one quite fundamental difference.
> >
> > So, one is wrong. Which on
> 
> regards,
> Kamal
> 
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 2 Apr 2004 08:58:12 +0200

Zhigang,

> specification.

I think we have still not reached an agreement on this point.
It seems like the logic would had been unambigous if TS had
never been constant, then scaling factor and "increase in TS
between two RTP packets" had obviously been the same. However,
as TS might be constant, one can argue that these two can not
be the same as one can not divide with a value of 0. On the
other hand, why should it not be possible to have a scaling
FACTOR of 0. I agree we can not have a scaling DENOMINATOR
of 0, but it is fine to have a factor of 0. 

> It is the compressor that decides whether TS 

Yes, it is an implementation issue, and to me the video example
seems to be a reasonable argument for enforcing the TS_STRIDE
definition from section 2, and thus allow it to be 0.
 
> Note: TS_STRIDE is not the same as slope described in section 

This proposal still does not address the original concern about
the concept of slopes not at all being defined in 3095. That is
the major issue here, I think.

/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 2 Apr 2004 09:21:53 +0200

Zhigang,

> Lars-Erik,
> 
> IMHO, we should clearly separate clarifying RFC 3095 from 
> redefining it:

Yes, absolutely, but since we are discussing things that are
not clearly defined in the specification, we must consider what
is actually there, and not what was the original intention. 

> - As I said, some text in RFC 3095 could have been written 
> better (though it doesn't mean we haven't tried). The slope 
> is one of them, in which case we should clarify what RFC 3095 
> intended to say.

Well, the motivation for clarifying anything at all is to ensure
interoperability, not necessarily to enforce principles that we
intended to build upon but never wrote in the specification. 
We need to find out what would be the smallest possible
deviation from the current spec, that would be consistent 
and ensure interoperability. The original intention is of
secondary importance

> - However, it is a completely different subject to say we do 
> not need slope. If that is indeed the conclusion at the end 
> of this discussion, we should define a new profile that 
> excludes it. Mixing this with above is not a constructive approach.

Since existing profiles are not defined by the original intention
of the authors, but rather by what is actually in the specification,
one could instead argue that a new profile would be needed to
*include* the concept of slopes. However, I do not think such
discussions are useful at this point, but we should first figure
out what are the possible approaches and what each of these
would imply in terms of "clarifications" to what is currently in
RFC 3095. Then we are ready to discuss which approach best
serves our objective of ensuring interoperability.

Cheers,
/L-E

---

From: [email-masked]
Date: Fri, 2 Apr 2004 13:07:56 -0500

Ghyslain,

This is amazing. I hesitate to say this, but what I see seems to be 
a campaign to make fundamental changes to RFC 3095, instead of 
genuine effort to clarify some misunderstanding/maturity in 3095.
I hope this is not the case.

I disagree with you on your three points. And here is why.

RE your first point:
- Do you call the fundamental of RFC 3095 a bug? The confusion is not 
caused by the presence of "non-SN-field = SN * slope + offset", 
but by its not being clear enough. The right thing to do is clarifying
it, not removing it.

RE your second point:
- TS_STRIDE is scale factor for TS, as clearly stated in section 4.5.3. 
Do you agree?
- TS_OFFSET and its calculation is clearly defined in section 4.5.3. Agree?
- Whether TS is scaled or not is indicated by Tsc. Agree?
- Do you mean you want to change all of above, instead of my simple
proposal to clarify the confusion caused by TS_STRIDE definition?

RE your third point:
- I don't understand. If you read through the email discussion by RFC 3095
authors and text in 5.5.1.2, the meaning of slope and default-slope is 
obvious. Why not just clarify that in the implementation I-D?
- Moreover, your interpretation is incorrect: slope is about the rate
of variation of a header field w.r.t. SN, not a parameter. 

BR,
Zhigang

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Ghyslain Pelletier
> Sent: 01 April, 2004 08:06 AM
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]
> Cc: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked]; 
> Kristofer Sandlund
> Maybe the way forward is to clarify the following in the implementer's
> guide:
> 
> - The informative text regarding "non-SN-field = SN * slope + offset"
>   in 5.5.1.2. was meant to be generic and informative, but introduces
>   confusion because it has no normative equivalent meaning;
>   Therefore it is a bug (void text);
> 
> - TS_STRIDE can be zero. Then should also be added that
>   "if STRIDE=0 then TS_OFFSET = TS" and that in such case the
>   Timestamp value is compressed as-is and cannot be scaled.
> 
> - The three occurances of default-slope should be interpreted as
>   a generic name for "the rate of variation of a parameter with
>   respect to the RTP SN, used to decompress this parameter".
>   Or something similar.
> 
> Regards,
> 
> /Ghyslain
> 
> "Lars-Erik Jonsson (LU/EAB)" wrote:
> > 
> > Zhigang,
> > 
> > Thanks for pointing us to this discussion in the archives, 
> it was useful reading at
> > least for me. Unfortunately, this is not what is captured 
> in 3095, and I think (at
> > least) we all agree that there is a need to resolve this 
> issue and make clarifications,
> > although we have not yet figured out and agreed on exactly 
> what to clarify and how.
> > 
> > As has been noted before, there are a number of questions 
> one may ask here:
> > 1) What was discussed during the development of 3095 in 1999-2000?
> > 2) What was 3095 intended to say, back in 2000?
> > 3) What is 3095 really saying?
> > 4) How can 3095 be interpreted?
> > 5) Now 2004, which solution do we think makes most sense, 
> technically?
> > 6) Now 2004, which solution would make most sense if we consider 3)?
> > 7) How do we realize 6) in the implementers guide to ensure 
> interoperability?
> > 
> > Kamal initially noted that it is unclear whether there 
> really is a slope. When I took a
> > first look at this issue by reading 3095 and the mail 
> thread Kamal had pointed to, my
> > observation was that 3095 is really not defining slopes. 
> One would have to read a lot
> > between the lines to find what Zhigang has explained was 
> the intended meaning. I
> > read the mails from Kristofer as if he also thinks there is 
> no slope defined in 3095,
> > but while Kamal believes there is a need to use implicitly 
> updated slopes, Kristofer
> > seems to be sceptical to that, although it is clear that 
> also a solution without the
> > implicit slopes means there are things that do not 
> "compile", e.g. TS_STRIDE=0,
> > which would have to be defined as it currently would result 
> in a division by 0.
> > 
> > We obviously are far from having answered questions 3-7, 
> and even if Zhigang has
> > explained much about 1-2, the history about why things are 
> like they are and what
> > was really intended at that time is still just background 
> information, we need to be
> > responsible, accept what we have, and find the proper 
> solution considering what
> > is really in 3095 today. It might also be so that our 
> preferred solution today, even
> > not considering 3095, will be different than what it was 
> back in 2000.
> > 
> > So, what I want you all to think of is to stay open-minded, 
> constructive, and be
> > nice to each other. We all have one single goal, to find 
> the best technical and
> > practical solutions and document them in an unambiguous 
> way. It is not about
> > being right or being wrong, it is about having the courage 
> to ask stupid questions,
> > and thereby getting the discussion forward. It is a good 
> thing to say, "ok, you
> > are right, I did not think about that", since that means we 
> (as a group) has
> > progressed and we have all learned something.
> > 
> > Keep up discussing, constructively, as we have a problem to resolve!
> > /L-E
> > 
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: den 31 mars 2004 20:19
> > > To: Lars-Erik Jonsson (LU/EAB); [email-masked]; [email-masked]
> > > Subject: RE: [rohc] Slope used to compress/decompress RTP
> > > Timestamp field
> > >
> > >

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Fri, 2 Apr 2004 15:37:30 +0200 (CEST)

Hi all,

I might've missed the start of this thread, but have been watching the
passionate discussion over recent days and am getting confused about
what the original point was. Hence, I thought I'd join in the fray
with my 2-cents worth... :-)

Looking back at the archives this morning, I guess the original
question was raised by Pawel regarding "slope", how it's defined, and
used.

I believe the general definition of the slope as being "the line
joining two points" (or something similar), which someone mentioned,
is pretty much my (2-dimensional) view as well. In my mind, "slope" in
RFC3095 was meant to be the general term for the difference of a
certain field, in consecutive packets. I further assumed that "slope"
for the TS field was labelled TS_STRIDE, which my following text
focuses upon.

Specific to the TS field, there should be no need for the decompressor
to determine any "slope"/TS_STRIDE at all, since the RFC states:

---<START: Snip from RFC3095 - Page 29>---
...
...
      TS = TS_SCALED * TS_STRIDE + TS_OFFSET

TS_STRIDE is explicitly, and TS_OFFSET implicitly, communicated to the
decompressor.  The following algorithm is used:
...
...

---<END: Snip from RFC3095 - Page 29>---

indicating, to my understanding, that the decompressor shouldn't have
to figure out "slope"/TS_STRIDE at all.

This assumption is consistent with my perception of the overall ROHC
algorithm, which makes the compressor out to be the intelligent
entity, capable of huge feats of analysis in order to generate the
optimally (small) header, while the decompressor is the "brute-force"
entity, not very bright, but able to handle all packets thrown at it
simply because it's provided all the necessary information by the
smart guy.

Someone also mentioned that TS_SCALED could look like: 2, 4, 6, 8, ...
which I don't quite follow. If the compressor initially notes the
delta between consecutive TSs is, say 320, it'll then explicitly
convey TS_STRIDE as 320 to the decompressor. It subsequently then
sends (say for a "well-behaved" RTP stream) UO-0 packets. If it later
notes that there is a delta of 160, it needs to explicitly inform the
decompressor that TS_STRIDE is 160, and subsequently send (say)
UO-1-TS packets whenever a delta of 320 is observed. In this scenario,
one delta of 160 would trigger the ROHC compressor to effectively
generate the larger UO-1-TS packet stream, instead of a UO-0 stream. A
smart compressor should probably notice this 2, 4, 6, 8, ...
behaviour and perhaps re-evaluate/rectify it's value of TS_STRIDE.

The point however is that the decompressor doesn't have to compute any
slope or deltas or stride values for the TS, but is explicitly told
what it is.

While this has all been my personal interpretation the "slope" and
TS_STRIDE is, I'm probably not alone in this since it should be also
pointed out that this has not been an issue during the four interops
taken place so far. While we never explicitly tested for this, it
would almost certainly have popped up if there were situations where
the compressor and decompressor were both independently trying to
figure out deltas/slopes/strides for TS.

Regards,
vick
+----------------------------------------------------+
 Vicknesan AYADURAI <[email-masked]>
 Ericsson Research: IP Networks - Stockholm, Sweden
 Phone :  +46 8 5087 8084 / Fax:  +46 8 404 7020
+----------------------------------------------------+

On Thu, 1 Apr 2004 [email-masked] wrote:

> Lars-Erik,
>
> IMHO, we should clearly separate clarifying RFC 3095 from redefining it:
>
> - As I said, some text in RFC 3095 could have been written better (though it doesn't mean we haven't tried). The slope is one of them, in which case we should clarify what RFC 3095 intended to say.
> - However, it is a completely different subject to say we do not need slope. If that is indeed the conclusion at the end of this discussion, we should define a new profile that excludes it. Mixing this with above is not a constructive approach.
>
> > So, what I want you all to think of is to stay open-minded,  constructive, and be nice to each other.
>
> I cannot agree more. And here is my understanding - if I may - on how to do it in practice (I've been trying them myself):
>
> - Be conservative of what you say. Try best to verify the reasoning/observations/facts on which you make a claim.
> - Everyone makes mistakes or has incorrect information. That's perfectly OK, but admit it.
> - Being nice to others means reading their emails *carefully*, especially when you disagree. If you agree, say so. If not, give reasons.
> - Be honest and straight to the point.
>
> BR,
> Zhigang
>
> > From: ext Lars-Erik Jonsson (LU/EAB)
> > [mailto:[email-masked]]
> > Sent: 01 April, 2004 06:32 AM
> > To: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked]; [email-masked]
> > Thanks for pointing us to this discussion in the archives, it
> > was useful reading at
> > least for me. Unfortunately, this is not what is captured in
> > 3095, and I think (at
> > As has been noted before, there are a number of questions one
> > may ask here:
> > 5) Now 2004, which solution do we think makes most sense, technically?
> > Kamal initially noted that it is unclear whether there really
> > is a slope. When I took a
> > first look at this issue by reading 3095 and the mail thread
> > Kamal had pointed to, my
> > observation was that 3095 is really not defining slopes. One
> > would have to read a lot
> > between the lines to find what Zhigang has explained was the
> > intended meaning. I
> > seems to be sceptical to that, although it is clear that also
> > a solution without the
> > implicit slopes means there are things that do not "compile",
> > e.g. TS_STRIDE=0,
> > We obviously are far from having answered questions 3-7, and
> > even if Zhigang has
> > not considering 3095, will be different than what it was back
> > in 2000.
> >
> > nice to each other. We all have one single goal, to find the
> > best technical and
> > practical solutions and document them in an unambiguous way.
> > It is not about
> > being right or being wrong, it is about having the courage to
> > ask stupid questions,
+----------------------------------------------------+
 Vicknesan AYADURAI <[email-masked]>
 Ericsson Research: IP Networks - Stockholm, Sweden
 Phone :  +46 8 5087 8084 / Fax:  +46 8 404 7020
+----------------------------------------------------+

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 5 Apr 2004 14:31:33 +0200

Vick,

Thanks for expressing your views on these matters as an implementer.
Especially the point about this never being an issue at the various
interops was really valuable.

/L-E

P.S. Thanks also for noting that it was Pawel who started the thread,
     I mistakenly wrote Kamal in my previous mail, sorry for that!!

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Vicknesan Ayadurai (KI/EAB)
> Sent: den 2 april 2004 15:38
> To: [email-masked]
> Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]; ROHC mail list
> Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp
> field
> 
> 
> Hi all,
> 
> > - However, it is a completely different subject to say we 
> do not need slope. If that is indeed the conclusion at the 
> end of this discussion, we should define a new profile that 
> > > So, what I want you all to think of is to stay 
> open-minded,  constructive, and be nice to each other.
> >
> > I cannot agree more. And here is my understanding - if I 
> may - on how to do it in practice (I've been trying them myself):
> >
> > - Be conservative of what you say. Try best to verify the 
> reasoning/observations/facts on which you make a claim.
> > - Being nice to others means reading their emails 
> *carefully*, especially when you disagree. If you agree, say 
> so. If not, give reasons.

---

From: [email-masked]
Date: Wed, 7 Apr 2004 16:31:30 -0400

Hi Vick,

> b. TS_new = TS_ref + (TS_STRIDE * (SN_new - SN_ref));

Here is what I had in mind (or section 4.5.3 meant to specify):

Step 1: TS_SCALED_new = TS_SCALED_ref + slope * (SN_new - SN_ref);
Step 2: TS_new = TS_SCALED * TS_STRIDE + TS_OFFSET

In other words, scaling is an additional step on top of the
"normal" (i.e. unscaled) compression.

>(at least it worked when we interop'd with Nokia's
> implementation before :-)

As I mentioned, this is probably because both interpretations
yield the same result for certain cases, for instance, Example 1
I gave in my earlier email. More general, this occurs when 
TS_STRIDE happens to be equal to slope. When they are not equal, 
we should see the discrepancy between the two interpretations.

BR,
Zhigang

---

From: [email-masked]
Date: Thu, 8 Apr 2004 09:32:50 -0400

> Yet another example of using both TS_STRIDE and slope is AMR 
> codec (widely used  in 3GPP). Normally the codec generates frames every 20 ms. 
> But during silence  periods, special frames (so called SIDs) are generated every 8*20 ms.
> 
> In my example TS_STRIDE is once at the beginning of the phone 
> call and is equal to 20 ms. While slope is changing during the call. Nomrally 
> the slope is equal to 1, but during silence periods it is equal to 8.

Good point.

BR,
Zhigang