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

Hi Zhigang,

comments inline.

zhigang.c.liu@nokia.com wrote:
>>Yes, of course the update packet itself has a CRC. But the slope value is not 
>>transmitted, it is inferred based on timestamp history so it is not covered by 
>>that CRC. 
> 
> 
> Kristofer,
> 
> An undetected error in an update packet can cause the decompressor 
> to derive an incorrect slope. But the problem is the undetected error, 
> not the slope. That is because the same error can happen in any
> transmitted header fields and parameters (e.g. SN, TS, TS_STRIDE)
> that will cause context damage and error propagation.
> 

In the worst-case example I provided earlier, the problem I was trying 
to point out was NOT the fact that the context _can_ get damaged, which 
I agree can happen at any time because of any field. The problem I was 
pointing out that we get context damage that will NEVER be detected on 
such a stream as I showed. In U/O-mode, context damage will be picked up 
quickly since all packets have a CRC, and in "normal" R-mode, almost as 
quickly (as soon as some context-updating packets arrive). This is what 
sets slope apart from explicit fields. So, my problem with slope is that 
when it is set (in a CRC-carrying packet) it is not used for this 
specific packet (therfore, the setting of the slope is not verified). In 
R-mode, the first time it will be used will (usually) be for a packet 
without a CRC, meaning that the slope itself might actually _never_ be 
verified. The only saviour is the R-0-CRC and there is nothing in the 
spec mandating sending of this specific packet type since a UOR2 could 
be used instead (in the worst-case stream, the compressor HAS to use 
UOR-2s).

Could you please comment on the worst-case mail, since to me this is a 
huge problem. You could (theoretically at least) have a video stream 
running for days in a row, without detecting that the context is damaged.

Also, the second-biggest problem to me is the actual updating of the 
slope (both in U/O and R-mode) and so far, the examples you have 
provided have only dealt with situations where the slope has already 
been set. It would be interesting to see some of this as well.

> To expand this. When TS breaks its change pattern (i.e. the function 
> TS = SN * slope + offset), at least one update packet needs to be sent. 
> (Actually, if new slope is same as default-slope, one update packet is 
> enough.) If an undetected error happens in SN or TS of that packet, the 
> function will be incorrect, no matter how you establish slope on the 
> decompressor side.
> 
> The issue of undetected (or residual) errors has been discussed heavily
> when we developed 3095. Actually, that is one of the core issues.
> Text in section 2, 4.6, 4.7 covers the subject.
>

See my reply above why I think these are two different problems.

> Also, I'm a bit curious: have you implemented R-mode? If yes, how section 
> 5.5.1.2 of 3095 was implemented?
> 

Yes, we have implemented R-mode. But we felt the same as multiple other 
implementers, that the "slope' part of that section was a leftover from 
something that did not make it into the spec since it is not really 
specified and therefore a "bug".

/Kristofer Sandlund, Effnet AB

> BR, Zhigang
> 

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