Subject: RE: [rohc] Shared mode

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Thu, 4 Nov 2004 11:41:47 +0100

Hi Abbie,

see my comments inline ...

> -----Original Message-----
> From: Surtees, Abigail [mailto:[email-masked]]
> Sent: Wednesday, November 03, 2004 6:04 PM
> To: Lajos Zaccomer (IJ/ETH); [email-masked]
> Subject: RE: [rohc] Shared mode
> 
> 
> 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.
> 

Yes, you're right. However, I didn't say "restriction". I said "warning in one of the guides". This is a consequence of the protocol. What I said still applies. As the bytecode is generally very small, the risk of accidental state removal is also much smaller.
One must also take the upper layer protocol into consideration. May this situation happen at all? Well, as far as I am informed, in PoC/SIP, this would never happen: after the client sent the initial REGISTER there must be an OK response. Even if the REGISTER message should be retransmitted, it would be done without recompression, lacking an answer. In this case, I can safely upload the bytecode (which is indeed mixed mode), and thereafter I could stick to either shared or dynamic compression in the server (in which case I also have the advantage to choose between them according to the first message).
In brief, I wouldn't like to see any kind of restriction in the guide (nither one shared state, nor dynamic XOR shared). I'd like to see some warnings what not to do some cases, illustrated with message sequences.

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

No, it was B that deleted the first shared state by saving its first dynamic state. So, I believe it is up to B to be prepared for such an event. But, this question is rather philosophical. The point is that we have a problem in the protocol, which the users of the protocol must be aware of, and they have to use it with much care. This is what the guide could help.

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

There is another possible solution, we have not considered, yet (just in case a simple warning would not fit the taste of our community ;-): compressor A should not save a second shared state until the first is freed by compressor B. This is basically the same as the one shared state solution, but we still have a chance to save new ones.

> 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
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 

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