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

Folks,

Unfortunately, it seems like I was wrong when I hoped we would be
able to easily close this issue, I got over-optimistic by the
sense of the room at the Washington DC meeting. The discussions
in March/April died with no conclusion and all involved parties
got tired of repeating the same arguments over and over again
without getting any closer to an agreement. Since then, I have
also had the feeling that this will require a detailed analysis
of the slope/non-slope algorithms, to be able to answer the
questions I earlier outlined, 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
However, it seems like this requires that someone seriously looks
at this problem from both perspectives so that everyone can see
what we have to decide upon. This will be resource-demanding, 
while I do not think it will be very tricky to write the final
clarifying text in the implementer's guide. As always, it is the
preparation work that takes time. I expressed this feeling both
in San Diego and in Washington, and although the response in
Washington was that we should not make this to complicated but
just get rid of slopes, I am still pretty sure after last weeks
mails on the list that we will have to spend some effort on this.

Personally, I am still sure there is no need for a learned slope,
and I can not see why we should expand the 3095 text and logic
to capture it, when something like it is only mentioned (but not
even close to defined) at a few places in 3095. However, that is
my opinion and others disagree, so I am afraid we might have to
do the detailed analysis before we will be able to get (at least
a rough) consensus on this.

However, I would like to make a few observations on what makes
me so confident in what is the "right" solution, apart from my
own opinion on the technical problem.

There are only two implementers whose implementations have made
it to all interop meetings, and who have thus learned ROHC RTP
from the specification, implemented it, got it to interoperate,
and also discussed/tested the TS encoding at an interop meeting
to get a clear opinion on the slope question. Their opinions
have been expressed in this ongoing mail thread:

Vick:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02097.html

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

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. A previous proposal for what
to clarify in the implementer's guide to get rid of the confusing
slope wordings can be found at:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02089.html
The attempts to clarify the slope concept and actually define it
have been much more complicated, which I also think is necessary
if we go that way.

BR
/L-E

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