Subject: RE: [rohc] Shared mode

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 3 Nov 2004 17:03:45 -0000

Hi Zacco, All,

Thanks for your feedback:
> 
> I completely agree with bullets a and c, on the other hand, 
> with the proposed solution, SigComp will make fun of itself. 
> Dying from the first lost message will prove to the potential 
> customers that this is a week protocol.
> To make it a bit clearer for possible newcomers: the problem 
> is not that a second shared state pushes out the first one 
> when the compressor of A saves it. It is that B saves a 
> dynamic state on A, which would push out the first shared 
> state. Now, if the message advertising the second shared 
> state is lost, B is in trouble not knowing the first shared 
> state is gone.
> Note that compressor A is not allowed to save a new shared 
> state if another state should be deleted as it is pointed out 
> in RFC 3321 5.2:
>   "Note that new shared state items must not be created
>    unless the compressor has made enough state memory available (as
>    decompression failure could occur if the shared state 
> pushed existing
>    state out of the state memory buffer)."

You are right, apologies for my confusing summary.  (There are some message
flows in previous mails on this subject which are clearer than words - for
more details see these
<http://www1.ietf.org/mail-archive/web/rohc/current/msg02384.html>)

> So, what is the problem here? I don't think it's the shared 
> compression, but the state handling algorithm used by 
> endpoint B. If an endpoint will not mix shared and dynamic 
> compression, this will not happen. Basically, it is an 
> endpoint responsibility not to use it, so in my opinion, 
> there should be nothing but a warning in one of the guides 
> that this mixed mode should be used with much care or avoided 
> if possible.
> 
> br/Zacco
> 

Adding a restriction to only use one of dynamic or shared mode could be a
solution, however, I think it is much more restrictive than the 'only store
one piece of shared state solution'.  If you only ever stored shared state,
you couldn't download bytecode at all and consequently the compression ratio
would suffer.

If you allow the two modes to be mixed then I think you need the restriction
we are suggesting (which I don't think implies that the protocol is weak).

In most protocols, if there is a problem, then it is obvious from looking at
the message flows which end has caused the problem.

For SigComp, looking at the flow would show that endpoint B has 'got it
wrong' because it has referenced a piece of state that is not present.
However, it is the behaviour of endpoint A (creating multiple pieces of
shared state which is currently allowed) that has caused endpoint B to
unknowingly reference state that is no longer available.  Consequently, in
this case, the safest thing for the a compressor to do is disable shared
mode.

The state handling algorithm in endpoint B in the example complies with the
state handling rules of RFC 3320.  However, RFC3320 also states that an
endpoint referencing state must be sure that it exists at the remote end.
The only ways in which B could be sure that the state exists are:

to only reference shared state in the direct response to the message that
advertised it (i.e. only in the first of the two messages B sends in the
example, the second would have to be sent without any state reference),

or

if B can be sure that endpoint A will only create one piece of shared state.

Consequently, if the restriction to one piece of shared state is not added,
then shared mode would only be usable in a very restricted case (direct
reply).

Adding the 'only one piece of shared mode state' rule still allows
shared-mode to be usable and useful and highlights that there is an issue
with state at priority 65535 and that if there a problem, that it may not be
the obvious endpoint (B) that has actually caused it.

Having said all this, we've been referring to shared-mode state as this is
the only use (that I know of, so far) of state with retention priority
65535; however, I think it should actually be a restriction to only create
one piece of state with that priority rather than restricting it to
shared-mode.

What do you think?

Best regards,

Abbie

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