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

> Let me give an example for a good argument that dynamic 
> slopes are not in 3095. 
> Consider section 6.5.
> This section was intended as the basis for future documents 
> describing  context transfer, so it lists all the state that a compressor/a 
> decompressor needs to maintain. 
> Dynamic slopes are not among this state.

Carsten,

That is because dynamic slopes were not considered worthwhile 
to transfer. The benefit of transferring dynamic slopes is
to stay in SO state during context transfer. However it's
complicated because the compressor may not be in SO state 
at the beginning or in the middle of a context transfer.

Of course, the point is debatable. But we really haven't
had a chance to discuss. I was one of the proponents of 
context transfer, but many other authors opposed the idea of 
context transfer at that time. As a result, context relocation 
is not mentioned by 3095 at all, and there has been no serious 
discussion/work on context relocation in ROHC.

In 3GPP, however, ROHC context relocation has been discussed and
adopted in TS 25.331 (I remember it's optional). There, SYN_SLOPE_TS
(the last synchronized slope of TS) was defined as an optional
parameter in context transfer.

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

BR, Zhigang

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