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

From: [email-masked]
Date: Thu, 1 Apr 2004 18:21:15 -0500

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

> -----Original Message-----
> 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]
> Subject: RE: [rohc] Slope used to compress/decompress RTP 
> Timestamp field
> 
> 
> 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
> 
> 
> 
> > -----Original Message-----
> > 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
> > 
> > 
> > > 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-arch
> ive/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-arch
> ive/msg00934.html
> http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch
ive/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

---

From: "kamal deep singh" <[email-masked]>
Date: Fri, 2 Apr 2004 18:16:57 +0200

Hi all,

I would like to thank L-E and Zhigang for their
encouraging words about the discussion and also for
making our discussion more focussed.

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

In addition I can only say that
We can try to give only clarification and clarification would mean only
clarification.
That is Not adding any concept and not removing any concept to or from RFC.
Adding any concept or removing any will result in new profile or new
standard.

I agree with L-E that we need to answer the questions which he has put
forward.
and as he again said that we need to all agree first on many points and have
to
figure out "on exactly what to clarify and how".

I feel that a clarification on "how to compress TS" is needed.

Please read below my clarification of compressing TS and I intend only
to use the concepts "that are given in RFC" and nothing else. Though I ALSO
"add examples" on how that concepts can be represented mathematically.
Please provide your comments on the example algorithm below.

In addition to what Zhigang has said, my clarification on TS compression is
as follows.

Please provide refinements.

TS Compression
-----------------

i) TS compression follows as quoted from RFC 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."
One of the ways (there are other ways too) to represent this function is:
TS = function(SN)
          or
TS (scaled or unscaled) = SN*slope + offset;

ii) offset and TS_OFFSET (in sec 4.5.3) are DIFFERENT as offset
refers to above equation whereas TS_OFFSET refers to the following equation:
TS = TS_SCALED*TS_STRIDE + TS_OFFSET which is used in TS scaled
Encoding. Scaled encoding is one of the encoding methods like WLSB.
Moreover scaled encoding is independent from compression and MAY or
MAY NOT be used but, in contrast compression MUST be used ALWAYS.

iii)So, to avoid the CONFUSION we will use offset2 as the word for
representing offset
from now and will leave TS_OFFSET (a parameter for scaling) as it is.

iv)"One of the ways" or algorithms of implementing the TS compression is as
follows:

Example algorithm:

COMPRESSOR SIDE
-----------------------

1. If Tsc = 0, then TS is compressed as is but,
    if Tsc = 1, then TS is first scaled by TS_STRIDE and then compressed.

2. If Tsc = 1 then TS_STRIDE needs to be communicated
    so that decompressor will know the TS_STRIDE value and side
    by side will calculate TS_OFFSET. Note that these above parameters
    are just used for scaling and descaling.

3. Compression.
           i) Compressor will send TS(scaled or absolute depending on Tsc)
              with SN.
           ii) As soon as Compressor is sure that decompressor has all the
              parameter for the pattern or the function TS = function(SN)
              ( i.e. TS = SN*slope + offset2 or (TS - TS_prev) = (SN -
SN_prev)*slope),
              it will stop sending TS bits and will just send SN going to SO
state.
             To quote from RFC "For transition from the FO to the SO state,
the
              compressor should be confident that the decompressor has all
              parameters needed to decompress according to a fixed pattern."

DECOMPRESSOR SIDE
---------------------------
1. Decompressor will use default value of slope as given in section 5.7 of
RFC
    unless updated. Note: that default value of offset2 is not needed if we
look
    at the equation in another way i.e. TS = TS_prev + slope* (delta SN);

2. If decompressor receives TS_STRIDE value then it will update TS_STRIDE
    and TS_OFFSET.

3. If it receives TS and SN then it updates the parameter of TS =
   function(SN). (Note one of the ways of representing this function is
   TS = SN*slope + offset2 and here decompressor will update slope
   and offset2)

4. If it receives only SN then it will calculate TS from TS = function(SN)

5. If Tsc = 1 then scaling was used. TS will be descaled by using
    TS_STRIDE and TS_OFFSET. i.e. by following:

    TS = TS(scaled resulting from 3 or 4.) * TS_STRIDE + TS_OFFSET

regards,
Kamal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 02, 2004 1:21 AM
Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field

> - 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.
> - Being nice to others means reading their emails *carefully*, especially
when you disagree. If you agree, say so. If not, give reasons.
> > http://www1.ietf.org/mail-archive/working-groups/rohc/old-arch
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00952.h
tml
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.h
tml
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.h
tml
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.h
tml