Subject: [rohc] sigcomp issue zliu-3: cannot recovery from decompression failure ?

From: [email-masked]
Date: Thu, 11 Apr 2002 11:32:52 -0500

Thanks Hans for a good summary on existing issues. I have to 
bring up one more as zliu-3 (I remember this has been somewhat 
discussed in different occasions but no follow up): how does 
SigComp recover from a decompression failure caused by 
reference to a corrupted or lost states (e.g. due to system 
failure at decompressor)? 

The problem is that the decompressor cannot send NACK to the 
sending compressor indicating such a failure because it 
does not know to whom it should send the NACK. The endpoint ID 
that sent a SigComp message can only be derived *after*
the message is successfully decompressed due to security
reasons. A potential deadlock?

Possible answers:
1) Let's forget about it as it rarely happens.
2) The application will resend the message. The compressor
can detect this and assume it is caused by decompression
failure and fallback to no state for compression of this
and subsequent message. However, this failure could be 
caused by message loss or corruption. Then the compression 
efficiency is unnecessarily sacrificed.
3) Find a way to enable NACK if possible at all.
4) Let's forget about it as it is unsolvable.

I have no good idea and would like to hear opinions from the WG.

BR,
Zhigang

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

---

From: [email-masked]
Date: Wed, 24 Apr 2002 14:32:28 -0500

Hi,

Can we allow a standalone RESET message from a decompressor
to its peer compressor indicating that it has lost the
dynamic states during a crash, and thus ask the compressor
to restart with only static states? Since security is
an obvious concern, let's assume the question is about 
an environment that you have secure channel under SigComp.

Of course, one solution is to let the application to signal 
the crash. But what if implementer does not want to change
the existing signalling (say SIP) message flow? Then it seems
that sending this signal at SigComp level will make the 
addition of SigComp much simpler and easier.

(This is actually a feedback I received from my colleague in 
3GPP even after I had explained the current thinking in IETF).

RB,
Zhigang