Subject: RE: [rohc] Shared mode

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Wed, 3 Nov 2004 08:13:56 +0100

Hi,

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Surtees, Abigail
Sent: Tuesday, November 02, 2004 6:26 PM
To: [email-masked]
Subject: [rohc] Shared mode

Hi All,

Before and at San Diego there was some discussion about a potential problem
with shared mode as it's currently defined in 3321.  For the gory details of
the discussion see
<http://www1.ietf.org/mail-archive/web/rohc/current/msg02384.html> and
subsequent messages.

In summary, if compressor A creates a second piece of shared mode state
there is potential for loss of synchronisation between endpoints A and B
(e.g. if the second shared mode state pushes the first piece of shared mode
state out but the message that does this does not reach B).

Our proposed solution is that the creation of only one piece of shared mode
state is allowed by any compressor (and the corresponding decompressor at
the other endpoint).  However, this has to be agreed by all SigComp
endpoints otherwise there is still possibility for loss of synchronisation
(see earlier messages).

Do others agree 

a) that there is a problem,
b) that allowing only one piece of shared mode state is a suitable solution,
c) that some text for this solution should be put in the implementer's
guide?

I understand that most of the above was agreed in San Diego, however, we
require consensus on the list in order to put the text in the implementer's
guide.

All comments are appreciated.  If I don't hear anything by Nov 19th (1 week
after Washington) then I'll take this as consensus and propose some text for
the implementer's guide.

Best regards,

Abbie

Abbie Surtees
Senior Engineer
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131

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

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Nov 2004 11:51:02 -0600

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

By the way, the ability to recover from these kind of situations was one 
of the strong motivations for the NACK document. If this is a truly rare 
occurrence, then I think the current situation combined with the use of 
NACKs is probably a suitable solution.

/a

---

From: "West, Mark" <[email-masked]>
Date: Thu, 4 Nov 2004 01:28:11 +0000 (GMT)

Adam,

We probably should have brought NACK into this sooner...  you're quite
right in suggesting that NACK is a way of recovering in the event of this
problem occuring.

A few comments, though:

- it's still worth (I think) documenting that a NACK based on failing to
find shared-mode state *probably* indicates a confusion of the form
described [for a well-behaved compressor].  (and, as a consequence,
shared-mode should no longer be used in this compartment)

- a communication involving a SigComp 'v1' endpoint will not be able to
take advantage of the NACK mechanism, so it would be nice to offer some
explanation of how to behave?

I still have a nagging doubt, though (and I'm sure you'll tell me if you
just think I'm being paranoid!) -- even with NACK, it is up to *my*
compressor to determine its risk level.  If I'm feeling conservative, then
I'll act in a way that tries to avoid NACKs.  This problem kind of
undermines that, I think.  If I don't know how your endpoint will behave,
my only prudent course of action is to not use shared-mode, except in
direct response to a received message.  If I can believe that your
endpoint will be more circumspect, then I can be more relaxed about using
shared-mode.

Having written and re-read this, I guess what I'm saying is that we need
to make a decision about what model we want for shared-mode.  There seem
to be two choices:
- 'full-speed ahead, and damn the torpedoes'; or
- only create one piece of shared-mode state

Depending upon which basic model we agree on, the trade-off for
compressors and the implementation choices that they need to make will
naturally follow.

FWIW, if we go with the first approach, my personal opinion would be to
disable shared-mode, because it's too risky.

However, in this case, I think that the WG needs to choose its risks..!
And I would agree that NACK makes it possible for either way to be
reasonably chosen.

Cheers,

Mark.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 4 Nov 2004 07:46:59 +0100

Mark,

your message confuses me.

When you say "the WG needs to choose" -- are you talking about changes 
to normative documents, or are you talking about the recommendations we 
are making for compressor implementers?

Gruesse, Carsten