Subject: [rohc] Feedback & Updating context

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 28 Apr 2004 13:17:55 +0200

Hi all.

I have a couple of questions on feeback updating properties that I would like to 
have clarified.

Question 1 - R-mode feedback and CRCs
---
Section 4.6 says:
     c) Feedback information can also be subject to residual
        errors, both when feedback is piggybacked and when it
        is sent in separate ROHC packets.  ROHC uses sanity
        checks and adds CRCs to vital feedback information to
        allow detection of some damaged feedback.

One "vital feedback" described in 3095 that I can see is the mode transition 
feedback, but I guess there can be others too. Since ACK feedback in R-mode is 
supposed to update the context of the compressor (by updating the reference), 
must all ACK feedback also carry a CRC option in this mode? If not, isn't it 
against the secure reference principle as context gets updated by a packet 
without a CRC?

Section 5.5.1.2. says that
      * It is possible, although unlikely, that residual errors
        on the reverse channel could cause a packet to mimic a
        valid ACK feedback.

But if the CRC is not mandatory, then I'd say it is not "unlikely". Having some 
kind of bit error on the feedback link could easily distort the SN to another 
"legal" value, even if the local clock algorithm of 5.5.1.2 is used. Or?

Question 2 - Discarding old references (R-mode)
----
Section 4.5.2 says:
     3) When the compressor is sufficiently confident that a
        certain value v and all values older than v will not
        be used as reference by the decompressor, the window
        is advanced by removing those values (including v).

Since "v" is supposed to be the field value (for example RTP SN), removing "all 
values older than v" _can_ be interpreted as all packets with "an older SN". If 
the spec is read this way, then R-mode can cause havoc if we had pre-link packet 
reordering (reordering BEFORE the compressor). I assume that "older value" 
should be based on packet arrival time instead of SN value, which probably 
should remove the risk of context getting out of synch. If so, I think a 
clarification in the implementers guide could be in order.

Best regards,
	Kristofer Sandlund, Effnet AB

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

---

From: [email-masked]
Date: Wed, 28 Apr 2004 13:44:11 -0400

Hi Kristofer,

Please see my answers in line.

BR,
Zhigang

> Since ACK feedback in R-mode is supposed to update the context
> of the compressor (by updating the reference), 
> must all ACK feedback also carry a CRC option in this mode? 

IMHO, must is a too strong requirement. It should be left to 
implementation to make the decision, since it depends on many 
factors. Some of them are:

- frequency of ACKs, which in turn depends on characteristics of
the packet stream being header compressed;

- the residual error rate on the reverse channel, which not only
depends on radio technology, but also dynamic radio conditions;

- bytes available on the reverse channel to carry ACK. If there
are more space, the decompressor may just send ACK with CRC all
the time, instead of wasting the space by padding.

- CPU cost to calculate CRC. This is probably less a concern
in most cases.

> If not, isn't it 
> against the secure reference principle as context gets 
> updated by a packet without a CRC?

No. Secure reference principle, as described in section 5.5.1.2
(text below), is more for the direction from compressor to decompressor. 
However, we did realize and discussed the possible corruption of ACKs. 
We considered it as a low probability event in general (see next answer) 
and introduced a few mechanisms (those you've mentioned) in RFC 3095 to 
address it in case the probability is high or considered high in implementation. 

   The secure reference principle is enforced in both compression and
   decompression logic.  The principle means that only a packet carrying
   a 7- or 8-bit CRC can update the decompression context and be used as
   a reference for subsequent decompression.  Consequently, only field
   values of update packets need to be added to the encoding sliding
   windows (see 4.5) maintained by the compressor.

> But if the CRC is not mandatory, then I'd say it is not 
> "unlikely". Having some kind of bit error on the feedback 
> link could easily distort the SN to another 

If I remember correctly, we (authors of RFC 3095) have discussed
the issue before the above text was accepted. I cannot recall the
details but here are some high-level reasons why it is "unlikely".
When you multiply all these factors, it can be seen that the probability
for a corrupted ACK to cause desync between compressor and decompressor
is very low.

1) ACK is expected to be infrequent
2) Size of ACK is small ==> the chance it gets hit is small.
3) When an ACK is hit by errors, it takes some good luck to mimic a
different "legal" ACK. The set of "legal" SN is small.
4) Even if the damaged ACK is legal, it has to correspond to an update 
packet that was actually lost on the forward diction (C->D).
5) Even if above is the case, it does not necessary lead to loss of
context sync (i.e. the decompression can be still correct even if
the compressor and decompressor use different reference).
 
>         is advanced by removing those values (including v).
<snip> 
> I assume that "older value" should be based on packet arrival 
> time instead of SN value, 

Right. That is why we specifically used word "older" instead of "smaller".