rohc

Interpretation of the exception, repair of CRC failure

Asked by Elisabeth

Dear Didier, ROHC team

How should the RFC exception case “repair of CRC failure” be interpreted?

The prior answers to questions related to CRC’s mainly added to the confusion.

From the questions/answers it looks to be related to too what extent the state transition of the decompressor state machine follows standard.

The code indicates that state transitions could/will happen upon CRC-failures, but from my quick look I could not determine whether all allowed state transitions where there.

So the basic question is probably, upon CRC-failures which causes the decompressor state machine to move from full context state, is it always required that an IR-message is received to come back to the full context state, or would UOR-2/IR-dyn messages be enough (in Static Context state)?

Best regards,
Elisabeth

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
Elisabeth
Solved:
Last query:
Last reply:
Revision history for this message
Didier Barvaux (didier-barvaux) said : 		#2

Elisabeth,

Here is my understanding of the § 5.3.2.2.3 of RFC 3095 [1] and the way the
ROHC library behaves.

According to the RFC, upon CRC failure:
1/ attempt a correction (there are 2 different algorithms that may be used),
2/ if correction fails in Full Context state, drop the damaged packet, then:
     a/ if the frequency of CRC failures on all decompressed packets is low, do
          nothing (no NACK, no state change).
     b/ if the frequency is too high, send a NACK if in O- or R-mode, then
          change for the Static Context state.
     c/ drop all received packets until one of IR, IR-DYN or UOR-2 packet is received.
3/ if correction fails in Static Context state, drop the damaged packet, then:
     a/ if the frequency of CRC failures on IR, IR-DYN and UOR-2 packets is low, do
          nothing (no NACK, no state change).
     b/ if the frequency is too high, send a STATIC-NACK if in O- or R-mode,
          then change for the No Context state.
     c/ drop all received packets until one IR packet is received.
4/ if correction fails in No Context state, drop the damaged packet, then:
     a/ send a STATIC-NACK if in O- or R-mode,
     b/ drop all received packets until one IR packet is received.

The ROHC library conforms to the RFC with the following limitations:
a/ the correction is never attempted [2],
b/ a frequency algorithm is used, but it is not the one described in the RFC [3].
c/ the negative ACKs are sent, but NACK is sent instead of STATIC-NACK in the
    Static Context.

So, to answer your question: no, IR packet is not always required. If the
decompressor was in the Full Context state when several CRC failures
occurred, the decompressor goes in the Static Context state. The next
UOR-2 packet is able to put the decompressor back in the Full Context
state.

I didn't understand your second question "Just found that the todo list
presented further details about this topic, i.e. that it is related to the
decompressor state changes and to SN wrap around". Please rephrase
it if you need an answer on that part ;-)

Regards,
Didier

[1] http://tools.ietf.org/html/rfc3095#section-5.3.2.2.3
[2] In fact, correction upon CRC failure was attempted in versions < 1.4.0,
       starting with 1.4.0 the feature was removed because the code was difficult
       to maintain and made some code refactoring very difficult. The feature
       remains to be added again.
[3] see the open bug https://bugs.launchpad.net/rohc/+bug/902465

Revision history for this message
Elisabeth (elilof) said : 		#3

Thank you Didier,

Your clarification of the exception and specification of the limitations solved my problem.

My mistake was to interpret the entire section 5.3.2.2.3 as “repair upon CRC failure”, thus also including the decompressor state machine transitions...

Best regards,
Elisabeth