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

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

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.

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

BR, Zhigang

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