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

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

Yes, a few e-mails were found that discussed this conceptually,
but, as also reflected in RFC 3095, all the details needed to
potentially get this to work was not at all nailed down. What can
be found in the archives does not make it clear what the actual
outcome was, as is also reflected in 3095 where "slope-ing" was
never really defined.

> 2) What was 3095 intended to say, back in 2000?
> 
> Above was what 3095 intended to say, in my opinion.

My conclusion is that there was no consistent consensus on
this issue, and the details were never worked out.

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

Yes, and scaling forms the SN-to-TS function through TS_STRIDE
(explicit) and TS_OFFSET (implicit). No mentioning of any 
implicitly learned slope.

> - Section 4.3.1.3 describes the function SN->X and SO state.

Yes, the "other fields based on SN"-principle is mentioned here,
but nothing about any implicitly learned slope.

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

If there is no function defined, there is no function, that's it.
No mentioning of implicitly learned slopes here either.

> - Section 5.2.7 describes the function SN->X and packet types/formats.

There is nothing here that talks about implicitly learned slopes.
E.g. the Packet type 2 text rather indicates that functions are
established explicitly, e.g. with UOR-2.

> - Section 5.5.1.2 describes the slope

This is the only place where slope is actually mentioned, and this
is an R-mode section only. This is the only part one can interpret
as if there was a generally applicable slope concept, but nothing
talks about implicit methods to establish parameters. One can rather
interpret this as a way to generally describe functions like the
TS scaling method, which is the only method that is defined to
use an implicitly established parameter.

> - Section 5.7 defines the value of default-slope.

Yes, and without any definition of either slope or default_slope,
this just creates confusion.

> 4) How can 3095 be interpreted?

As you use to say, "I get speechless". Do you really mean that
you think the text pieces in 3095 defines implicitly learned
slopes and all the principles needed to get this to work and
interoperate?

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

What is implied is that whatever we do, we must ensure we have 
an understanding of the alternatives we are discussing. It is clear
that the RFC is ambiguous and in practice impossible to create
interoperable implementations from. Considering that what is actually
in the RFC is the basis we will build on, not the ideas from some
authors that were never nailed down and thus not captured in the RFC,
what we technically think about the alternatives today and their
relation to what is described in 3095 will indeed be very important
when deciding on what elaboration/clarification to provide to
implementers.

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

Considering the complexity of the implicitly learned slope mechanism,
the fact that it does not at all exist in 3095, it seems like most
people agree it is not what we should now add to 3095 profiles.

> 7) How do we realize 6) in the implementers guide to ensure 
> interoperability?
> 
> I think we haven't reached this yet.

Agree, but we seem to be going towards defining two different
proposals, and that might help in deciding upon 6).

/L-E

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