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

From: [email-masked]
Date: Fri, 2 Apr 2004 12:06:58 -0500

Ghyslain,

> My take is that although it may seem as if there was an agreement in
> older mail list discussions regarding the use of a "slope" and how to
> "learn a slope", 

It's not "may seem as if ...", it is the *fact*. 

> I can not find that this resulted in any normative text
> anywhere in 3095; therefore I tend to agree with Kristofer as to that
> these concepts do not exist in 3095.

As I mentioned earlier, we thought the text about function from SN to 
non-SN field (described in section 3.4, 4.1, 4.3.1.3, 5.2.7, 5.7.7.1
and 5.7.7.2) covers the slope, which is a parameter of the function.
Also, we defined default-slope so that it can reduce synchronization
overhead in the cases where the default-slope fits the property of
packet streams. That itself indicates that 3095 expects the compressor
to use a different learned slope.

Having said that, I do agree that RFC 3095 would be clearer if we had 
included more text on slope (e.g. those email discussions). At that
time, 3095 authors didn't think it's necessary. However, now that
the question was raised, we should clarify it in implementation I-D, 
which is setup to clarify ambiguous points.

> Also, I wonder why this additional "learned slope" would help 
> at all. 

This has already been discussed and concluded in the old email 
thread which I pointed out and you said you have looked through. 

> If TS_STRIDE represents the expected increase in the timestamp value
> between two RTP packets with consecutive sequence numbers, 
> what is this slope trying to correct? 

As I repeated many times (sorry for those who must be tired of this):

1) The definition of TS_STRIDE in section 2 is misleading. I've proposed
text to clarify that.
2) TS_STRIDE is a scale factor, this is clear from section 4.5.3. 
3) Scaling is a further optimization for TS, on top of the basic 
compression scheme (SN to non-SN function, slope and offset, etc).
Also clear from section 4.5.3.
4) Scaling is secondary to slope and offest. You can compress without
scaling. Again, clearly stated in section 4.5.3 and other places in 3095.

> Also, regarding the following text in 5.5.1.2.
> 
>    For example, in a typical case where the string
>    pattern has the form of non-SN-field = SN * slope + offset, one ACK
>    is enough if the slope has been previously established by the
>    decompressor (i.e., only the new offset needs to be synchronized).
>    Otherwise, two ACKs are required since the decompressor needs two
>    headers to learn both the new slope and the new offset.  In the SO
>    state, R-0* packets will be sent.
> 
> This, in my opinion, is informative text - it does not specify anything.
> Furthermore, I cannot find any normative equivalent or any normative
> follow-up to this anywhere in 3095.

The text further explains the concept of SN to non-SN function, which
is the fundamental to RFC 3095 (and in fact those header compression
RFCs preceding 3095). I used the word "for example" because not all SN 
to non-SN functions are linear. 

BR,
Zhigang

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Fri, 2 Apr 2004 23:59:08 +0200

hi all,

I agree with Zhigang.

Instead of opposing his concepts totally, we should
only provide refinements if any.

In case of disagreement, it will be helpful if one tells the points with
which one disagrees and "why so".

regards,
Kamal