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

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

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

---

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

Hi all,

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

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