Subject: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompression fail ure ?

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Fri, 12 Apr 2002 10:17:05 +0200

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

I would say that the potential deadlock depends on how your implementation behaves. 
 
> Possible answers:
> 1) Let's forget about it as it rarely happens.

It is probably true that it rarely happens, but one (at least the implementer) should not forget about it.

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

This seems like a solutions that would work.

> However, this failure could be 
> caused by message loss or corruption. 

True. 

> Then the compression 
> efficiency is unnecessarily sacrificed.

A compressor implementation would have to weigh the possibilities that the message is resent due to decompression failure, message loss or corruption. Then it should decide in which form it should resend the message; compressed, uncompressed, "restarting" compressed message.  

> 3) Find a way to enable NACK if possible at all.

This seems to be hard because of the security reasons.

> 4) Let's forget about it as it is unsolvable.

You could use 2) above.

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

Well, I think that 2) do sounds like a good idea. In my opinion that would not be a standardization issue for the ROHC WG, but rather an implementation issue -> "implementers guide".  

BR,
/Hans H 

> BR,
> Zhigang

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