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

From: [email-masked]
Date: Wed, 8 Dec 2004 19:21:40 -0500

Kristofer,

> The problem I was pointing out that we get context damage 
> that will NEVER be detected on such a stream as I showed. 

My understanding of your example is that an undetected error
in an update packet (say X) can lead to a wrong slope on the 
decompressor side. However, the undetected error in X will be 
likely (if not absolutely by theory) detected when the 
compressor sends the next update packet Y. Note that Y uses X
as reference. Once the context damage is detected, NACK(s) will
be sent by decompressor and compressor will re-establish context,
including slope. 

Also to put things into perspective, the chance of an undetected 
error in an UOR-2 packet is low, should be less than 1/128 due 
to 7-bit CRC. In practice, it should be even lower since residual
errors are *real* headache to ROHC (see section 5.3.2.2.5).

Another note is that R-0-CRC has to be sent at least every 64 SO 
packets. That curbs the residual error propagation. Of course, this 
does not help for a short SO state like in your example. If the 
compressor is unsure, it should send R-0-CRC in the middle of a string 
even if it doesn't have to. Or, it can re-sync the slope even if
it is the same as the previous string.

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

Please see above.

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

I guess your question is what happens if current slope != default-slope? 
I think I explained in the email to Carsten. But let me know if
I wasn't clear.

BR, Zhigang

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Dec 2004 08:36:35 +0100

> as reference.

But it won't use any "slope" component of X as a reference unless it is 
a R-0-CRC.
I think that has been Kristofer's main concern:  A dynamic slope 
element of the context would not be protected by a CRC in any other 
header than R-0-CRC (and a few more less likely cases that also don't 
explicitly send a timestamp such as UOR-2-ID).

> errors are *real* headache to ROHC (see section 5.3.2.2.5).

One would hope so.
Unfortunately, hope is a not really a legitimate protocol mechanism :-)

> packets.

I think Kristofer's example shows that this may not always be the case, 
because you may be forced to send context-updating packets that do 
include a TS.
The part I'm not sure about is why Kristofer thinks these wouldn't 
update the dynamic slope, too.
(I don't think anyone has proposed a detailed algorithm for when/how 
exactly dynamic slopes would be updated, yet.)

> That curbs the residual error propagation. Of course, this
> even if it doesn't have to.

Requiring the compressor to periodically send slope-validating headers 
(i.e., with CRC, but without TS) would indeed solve Kristofer's issue.
(This is, essentially, including a grain of U/O mode thinking into R 
mode, just to cover the dynamic slope which is not protected by the 
CRC.)

Gruesse, Carsten