Subject: [rohc] SigComp recovery mechanism

From: "Price, Richard" <[email-masked]>
Date: Wed, 23 Oct 2002 15:53:55 +0100

Hi,

I've been asked to provide some clarification on how
SigComp can recover from state loss at an endpoint -
in particular what can be achieved as an implementation
decision in "ordinary" SigComp, and what can only be
achieved with additional standardisation.

If a SigComp compartment needs to be reset for whatever
reason then "ordinary" SigComp can communicate this
using the built-in feedback mechanism by sending a
state_memory_size of 0. Subsequent messages can then
change the state_memory_size back to its original value,
allowing new state to be stored in the compartment.

SigComp feedback can be sent piggybacked or standalone.
In the latter case enough lower-layer security must be
provided to prevent malicious standalone messages from
being forged.

However, what's missing from "ordinary" SigComp is the
ability to indicate precisely why the state is no
longer available. State loss due to lack of memory is
indistinguishable from state loss due to dropped or
corrupt messages and so on. For this reason
<draft-roach-sigcomp-nack-00.txt> proposes a detailed
list of error conditions that can be used to NACK
failed SigComp messages with an indication of exactly
what's gone wrong. In some cases the sender may be able
to recover more quickly than just resetting the
compartment and starting over again.

I don't believe that the two approaches outlined above
are contradictory - the decision that needs to be made
by the Working Group is whether the benefits of a
detailed NACK mechanism outweigh the additional
standardisation effort...

Regards,

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