RE: [rohc] The discussion on slope(s)

Lars-Erik and Others,

> which is the way I still think we
> will have to go to get closure on the issue:
> http://www1.ietf.org/mail-archive/web/rohc/current/msg02085.html

I think I've answered - from my perspective - most of the questions
asked in the above email.

> 1) What was discussed during the development of 3095 in 1999-2000?

I've provided emails on ROHC mailing list where Mickael and I discussed
about the synchronization of the slope. The conclusion was that compression
starts with default-slope and then use "learned slope" if default-slope
is not good. Video example was discussed as one reason for that. It
was also clear that slope is a separate concept from TS_STRIDE, which
is a scale factor.

2) What was 3095 intended to say, back in 2000?

Above was what 3095 intended to say, in my opinion.

3) What is 3095 really saying?

As result of above and other discussions:

- Section 3.4 describe the function from SN to other fields X.
- Section 4.3.1.3 describes the function SN->X and SO state.
- Section 4.5.3 defines the scaling of TS before compression.
Note: scaling and thus TS_STRIDE is optional. While WLSB is
not. Neither is SO state. It should be self-evident that
TS_STRIDE is not the slope.
- Section 5.2.7 describes the function SN->X and packet types/formats.
- Section 5.5.1.2 describes the slope (yes, it should be put in
earlier sections. See below.)
- Section 5.7 defines the value of default-slope.

>From what I heard, there are two major sources of confusions about this:
- The definition of TS_STRIDE is section 2. It's not accurate and
makes people think TS_STRIDE is the slope. But it is isn't. It's
probably caused by glitch between different authors.
- The text on slope is in R-mode section. I don't know what exactly
happened. But following are probably some of the factors:
1) Because of work distribution, people knowing most about a technical
subject didn't get a chance to write the corresponding section.
2) We were under time-pressure. Not everyone reviewed rigorously
or cross checked every aspect of 3095.
3) 3095 was so long that making it shorter became one of the goals.
Unfortunately, some clarification text (e.g. those proposed during
email discussions) were left out in the final version. In retrospect, 
they would help to avoid confusions.

4) How can 3095 be interpreted?

See above.

5) Now 2004, which solution do we think makes most sense, technically?

I'm a bit confused, and this is the difficulty I have. What is the
question in this discussion: a) learned slope or even slope doesn't
ever exist in 3095? b) even if it exists, we can re-evaluate and 
decide to remove it (what is implied above)?

Anyway, I've given my opinions on both.

6) Now 2004, which solution would make most sense if we consider 3)?

See above.

7) How do we realize 6) in the implementers guide to ensure interoperability?

I think we haven't reached this yet.

> This will be resource-demanding, 

Yes, it is. But this is a serious issue and we need to resolve it.
I've been devoting my time to read, reply, explain, give examples. 
It's fair to say people with interest should try the same.

> There are only two implementers whose implementations have made
> it to all interop meetings, 

Vick and Kristofer's work is certainly valuable to ROHC. I used to
do lots of coding so I understand how important it is. There are 
also other implementers that didn't make all the interop meetings 
due to various reasons. I know that the implementation team in
Nokia implemented learned slope. Unfortunately, as I explained earlier, 
the interop tests didn't reveal the different understandings (
the test cases were not comprehensive enough).

Also, Pawel (who started the discussion) and Kamal seem to agree
with me. I don't know if they have done some implementation. But
their opinions are derived from reading of 3095 and discussions
in March/April.

> http://www1.ietf.org/mail-archive/web/rohc/current/msg02081.html
> (the last one included questions to Zhigang, which were ignored)

I probably missed Kristofer's email. It's not easy for me to
read/reply so many emails although I tried. I'll reply him in 
a separate email.

> Finally, I would like to send a direct appeal to Zhigang, as a
> comment on yesterday's mail on this subject:
> 
> > ZL:
> > I think it's fair to also look at the arguments that dynamic
> > (or learned or implicit) slopes are in 3095. I have given some
> > back in March/April. Below is one of them. If I have to summarize
> > in one sentence, the argument is that if dynamic slopes are not
> > in 3095, many text (some are essential to encoding) wouldn't 
> > make sense without twisting hard the meaning of words.
> > http://www1.ietf.org/mail-archive/web/rohc/current/msg02101.html
> 
> Can you then list these parts, please cut and paste the sentences
> in an e-mail, do not use references. 

I thought providing a link is a better way than resending the same
email. But I'll do it as you wish.

BR, Zhigang

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc