Subject: RE: [rohc] RE: sigcomp issue zliu-3: cannot recovery from decompr ession failure ?

From: "Price, Richard" <[email-masked]>
Date: Fri, 12 Apr 2002 14:11:38 +0100

Hi,

How about the following solution:

5) A compressor should not reference the same state item more
   than N times.

This prevents a corrupted or lost state from causing more than
N SigComp messages to be unsuccessfully decompressed. It's
similar to 2) except that there is no need for the compressor
to be "application-aware" (i.e. no need for it to detect
retransmissions).

When SigComp is operating correctly the above restriction has
no effect on the compression ratio, because states are not
normally referenced by more than one SigComp message. The
solution only has an effect when the compressor does not receive
acknowledgements for a long period of time (in which case it
may continue to reference the same state item in many SigComp
messages). In this case it is prudent to stop referencing the
state after a while, just in case the state is lost or corrupt.

As Hans mentions, this is an implementation choice at the
compressor and something that we should consider for the
implementer's guide.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 9:17 AM
> To: [email-masked]'; [email-masked]
> Subject: [rohc] RE: sigcomp issue zliu-3: cannot recovery from
> decompression fail ure ?
> 
> 
> > 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
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Apr 2002 20:17:04 +0200

> 5) A compressor should not reference the same state item more

I'm not sure there's a good N.
If we are going down this path, I'd rather see a time limit, because 
it's recovery time that really is going to influence the user experience.

> normally referenced by more than one SigComp message. 

I'm not sure that's true for the simplest implicit ACK case.

> compressor and something that we should consider for the

Right -- this should be documented as one of many ways to handle the 
problem.  Certainly not a normative thing.

I believe we should stress in the document that sigcomp works best if 
there is fate-sharing between the compression state and the application 
state.

Gruesse, Carsten