Subject: [rohc] SigComp Recovery

From: "Jan Christoffersson (EAB)" <[email-masked]>
Date: Thu, 24 Oct 2002 13:52:10 +0200

Hi,
I have a few questions or comments to the two recently submitted drafts on SigComp recovery (draft-roach-sigcomp-nack-00.txt and draft-liu-sigcomp-recovery-00.txt.

I question the need for detailed feedback other than for missing or corrupted states. It has been the idea that the compressing side is responsible for not using to much resources at the decompressing side and having a byte code that works correctly. I don't doubt that the proposed NACK mechanism is very useful when developing and testing the Sigcomp software, but is it really needed in a final Sigcomp implementation?

I can imagine that trying to access a state that no longer exists at the decompressing side can be problem. Sending a state_memory_size of 0 might be a little to drastic (no states, except mandatory states, are available for decompression). But aren't all the tools to detect this problem already available in Sigcomp? The decompressing endpoint can send a list of all its available states and in this way indicate that the state the compressor wishes to use is not available? 

Why not write a section on this in the SigComp User Guide saying that the receiving endpoint should respond with a list of available states in case of compression failure? If the response can be sent stand alone this would be really useful.

Let's not make this more complicated than it has to be.

Best Regards
Jan

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

---

From: [email-masked]
Date: Thu, 24 Oct 2002 10:06:01 -0500

Hi Jan,

> I question the need for detailed feedback other than for 
> missing or corrupted states. 

I have the same question. That's why in my draft I propose
to define just a single RESET signal to indicate loss of 
synchronization. IMHO, I don't think we need more than that. 

> It has been the idea that the 
> compressing side is responsible for not using to much 
> resources at the decompressing side and having a byte code 
> that works correctly. 

I agree. As stated in the introduction, I think the primary
mechanisms to maintain synchronization are those defined in
sigcomp and sigcomp-extended spec. E.g., compressor sends
byte code to decompressor which sends acknowledgement back.

However, states can be corrupted or lost *after* they are 
acknowledged. In that case, the RESET signal is needed
to indicate it. Note that what is missing is current
spec is a standardized definition of RESET so that every
sigcomp endpoint can send and understand it.
 
> I can imagine that trying to access a state that no longer 
> exists at the decompressing side can be problem. Sending a 
> state_memory_size of 0 might be a little to drastic (no 
> states, except mandatory states, are available for 
> decompression). 

I agree. In addition, the sending endpoint has to re-announce
state_memory_size to a non-zero value afterward. That takes
another round trip time and delays the recovery. I.e., before
the second announcement, the other endpoint cannot re-upload
states with confidence that it will be accepted by the receiver.

> But aren't all the tools to detect this 
> problem already available in Sigcomp? The decompressing 
> endpoint can send a list of all its available states and in 
> this way indicate that the state the compressor wishes to use 
> is not available? 

Again, RESET signal is complementary to existing synchronization
mechanisms like the one above. It is clarified in section 3.3,
page 6 of my draft. However, you still need a RESET signal to
say "by the way, other states are gone".

> Why not write a section on this in the SigComp User Guide 
> saying that the receiving endpoint should respond with a list 
> of available states in case of compression failure? 

See above. We need a RESET signal to differentiate two cases:

a) one endpoint simply tells the other end a list of available
states. That does not mean they are the only one. 

b) one endpoint wants to tell the other end that ONLY the listed
states are available.

> If the response can be sent stand alone this would be really useful.

Agree. That is another dimension of this problem. It looks to me
that in IETF, we can only assume the generic ("conservative")
security model. But when SigComp is applied to a particular 
environment (e.g. 3GPP), stand alone sigcomp message can be
allowed based on the underlining security.

However, a good recovery mechanism should be able to handle
both piggybacking and standalone cases.

> Let's not make this more complicated than it has to be.

I share the same philosophy. The RESET signal in my draft is
as simple as it can be: simply announce the state defined
in the document. That's it!

Zhigang

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Oct 2002 15:05:02 -0500

> missing or corrupted states. 

Admittedly, the list of errors reported can be pared down if
there is consensus that they aren't useful; however, I think
there is at least one other case that might warrant reporting:
Richard raised the excellent point that reporting back the
information that there has been a state-ID collision (based
on the state ID length used) can be quite usefully employed by
the sender to recover.

This allows senders to safely be rather terse when identifying
states, with the ability to be more specific if there is
a collision.

I don't beleive a simple "reset" operation solves this problem.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Oct 2002 15:31:37 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>

I think you might.

It's not immediately clear how the RESET states described in
your solution are resolved to an appropriate compartment. Did
I miss something?

/a

---

From: [email-masked]
Date: Thu, 24 Oct 2002 19:42:06 -0500

> your solution are resolved to an appropriate compartment. Did

Adam,

That can be done as long as the receiver can determine who sends
the announcement of RESET state. There is nothing new here. In case 
the announcement is piggybacked on a compressed application message, 
the receiver can derive compartment ID from the application message. 
In case the announcement is sent standalone, well, that means we 
already have means to derive the compartment.

However, when I wrote the draft, I did pause for a while for a 
related question. That is, do we need the signal to be per-compartment, 
per-endpoint or do we need both? It wasn't entirely clear to me (see below). 
Due to time pressure, I defined the *semantics* of the RESET state as 
per-endpoint in the draft. However, if we need both, we can define 
another state that means "reset only for a particular compartment".

Now getting to the dirty details. The only case we may need reset
per-compartment is when two (compressor) compartments at endpoint A 
talk to two (decompressor) compartments at endpoint B. Let's call them
X and Y. It is possible somehow, compartments X at endpoint B loses 
its states, but not compartment Y. In that case, it would be 
efficient if B can tell A that only compartment X has lost its states.
Note however, even per-endpoint RESET can handle this, though in a
less efficient way. Namely, B can announce per-endpoint RESET together
with the state IDs for compartment Y (see section 3.3).

BR,
Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 28 Oct 2002 17:17:22 -0000

Hi,

This raises an interesting issue on how SigComp implementations
react when the remote endpoint advertises a state_memory_size of 0.

When a SigComp message is received which announces that the
state_memory_size at the remote endpoint is 0, the local compressor
has two choices on how to proceed:

1.) Avoid making state creation requests until a non-zero
    state_memory_size is advertised by the remote endpoint.

2.) Make state creation requests anyway in the hope that state
    memory will be available by the time the messages arrive at
    the remote endpoint.

The cost of making a state creation request is around 5 bytes, so
following Option 1 saves this amount in each SigComp message for
which no state memory is available. However, if state memory
becomes available but is not used then Option 1 costs several
hundred additional bytes due to uploading the decompression
algorithm to the remote endpoint more times than is necessary.

The choice of which option to follow is up to implementers of
SigComp, but if the best overall performance is desired I'd
strongly recommend using Option 2. The reason is that Option 2
maximises the compression ratio when new state memory becomes
available, which is the case where SigComp is working correctly.
Option 1 saves a few bytes when state cannot be saved, but the
compression ratio is already very low in this case. The only
case where I'd avoid making state requests is if the endpoint
never offers a non-zero state_memory_size (indicating that it
is a stateless endpoint).

Is anyone planning to implement SigComp using Option 1? The
reason this is interesting is that Option 1 is the only case
where a special "RESET" code invokes different behaviour compared
with setting the state_memory_size to 0. If Option 2 is followed
then in both cases the compressor stops accessing previously
saved state, but still continues to make new state creation
requests in the hope than more state memory will become available.

Regards,

Richard

---

From: [email-masked]
Date: Mon, 28 Oct 2002 11:56:09 -0600

Hi Richard and others,

The analysis below seems to assume the only state to be uploaded
is the decompressor bytecode. In that case, implementation
clearly should try option 2 since there is nothing to lose except
the overhead of state creation request which is small. I.e. the
price of "hope" not matching reality is small.

However, the compressor may upload other states (e.g. user-specific
dictionary) in addition to decompressor bytecode to boost compression 
efficiency. In that case, the different is not merely 5 bytes any more. 
The state could be hundreds of bytes. Therefore, compressor has to know 
the state_memory_size in order to decide whether to upload the state.
If the "hope" does not realize, all the overhead is wasted with nothing
in return. In other words, we need to separate state_memory_size = 0 
from RESET. Logically, they are different things.

BR,
Zhigang

> From: ext Price, Richard [mailto:[email-masked]]
> Sent: October 28, 2002 11:17 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: SigComp Recovery
> 
>

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 29 Oct 2002 17:34:25 -0000

Hi,

The assumption that I'm making is that the compressor
typically only saves state which already needs to be uploaded
to the decompressor in order to successfully decode the
message. This includes the UDVM bytecode and also any text
strings from the message itself.

In some cases the compressor may wish to pre-upload state that
isn't needed by the current message, but may be useful for
improving the compression ratio of subsequent messages (e.g.
the static or user-specific dictionaries). However, uploading
this extra state only improves the call setup time if it can
be done a-priori, during the non time-critical portion of the
signalling exchange. In this case it's no problem to wait for
an extra RTT before recovering from state loss.

> In other words, we need to separate state_memory_size = 0 

Announcing a RESET code certainly has a different meaning to
setting state_memory_size = 0 (it conveys that the previously
saved state is unavailable, but promises to offer the original
state_memory_size for subsequent state creation requests).
However, in order for this extra information to be useful for
more than just debugging implementations, we need to discover
cases where endpoints can use the information to recover more
quickly from error cases (thus improving the overall
performance of SigComp).

Providing a RESET code on its own probably doesn't offer enough
benefit to justify the extra standardisation effort. However,
by specifying a more detailed list of error conditions such as
"STATE NOT FOUND", "STATE ID TOO SHORT" etc. we can provide a
further performance benefit: for example if an error occurs
because the state ID is too short then the compressor knows
exactly what to do in order to recover (send a longer state ID!).

If we decide to make the effort to standardise some kind of
reset/nack mechanism, I'd propose to maximise the benefit from
this work by making the list of error conditions as detailed as
possible.

Regards,

Richard

> Sent: Monday, October 28, 2002 5:56 PM
> To: Price, Richard; [email-masked];