Subject: RE: [rohc] Shared mode

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 5 Nov 2004 14:18:39 -0000

Hi Zacco,

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

Yes, this is a good suggestion.  It is creation of a second piece of minimum
priority state that causes a problem so freeing the old one first also
solves the problem.

We seem to be converging on potential solutions, so I've written some
proposed text for the implementer's guide.  This is more than a warning, but
hopefully it is also unrestrictive enough that you will be happy with it too
and we can reach WG consensus.

Let me know what you think:

"Retention Priority 65535 (or -1)

   There is potentially a problem with storing multiple pieces of state
   with the minimum retention priority (65535) as defined in SigComp
   [1].  This can be shown by considering the following examples, which
   are of shared mode SigComp Extended [2] .

   Example 1:

       Endpoint A                  Endpoint B
       [decomp cpt]                [comp cpt]

       [SM1]
       ------------------------------->
                                   [SM1]

       [SM1, SM2]
       --------------------X (message lost)

                                   [SM1, BC, BF1]
       <------------ref SM1------------
       [SM2, BC, BF1]
                                   endpoint B still believes SM1
                                   is at endpoint A

                                   [BC, BF1, BF2]
       <------------ref SM1------------

       decompression failure at A
       because SM1 has already been deleted

   Example 2:

       Endpoint A                  Endpoint B
       [decomp cpt]                [comp cpt]

       [SM1]
       ------------------------------->
                                   [SM1]

                                   [SM1, BC, BF1]
       (message lost)X------ref SM1-----

       [SM1, SM2]
       ------------------------------->
                                   endpoint B does not create SM2
                                   because there is no space
                                   [SM1, BC, BF1]

                                   [SM1, BC, BF1, BF2]
       <------------ref SM1------------
       [SM2, BC, BF2]
                                   endpoint B still believes SM1
                                   is at endpoint A

                                   [BC, BF1, BF2, BF3]
       <------------ref SM1------------

       decompression failure at A
       because SM1 has already been deleted

              Figure 2: Retention priority 65535 examples

   Once there is more than one piece of state of minimum priority state
   created in a decompressor compartment, the corresponding compressor
   cannot be certain about which pieces of state are present in that
   (decompressor) compartment.  If there is only one piece of state,
   then no such ambiguity exists.  The problem is a consequence of the
   different rules for the creation of minimum priority state.  In
   particular, the creation of the second piece of state without the
   knowledge of the compressor may mean that the first piece is pushed
   out earlier than the compressor expects (despite the fact that the
   state processing rules from SigComp [1] are being implemented
   correctly).

   SigComp [1] also states that a compressor MUST be certain that all of
   the data needed to decompress a SigComp message is available at the
   receiving endpoint.  Thus it should not reference any state unless it
   can be sure that the state exists.  The fact that the compressor at B
   has no way of knowing how much state has been created at A can lead
   to loss of synchronisation between the endpoints which is not
   acceptable.

   One observation is that it is always safe to reference a piece of 
   minimum priority state following receipt of the advertisement of the
state.

   If it is known that both endpoints are running SigComp version 2 as
   defined in NACK [4], then it may be reasonable to assume that the
   likelihood of loss of synchronisation is very small and rely on the
   NACK mechanism for recovery.

   However, for a compressor to try and avoid generating NACKs, it has
   to be able to make some assumptions about the behaviour of the peer
   compressor.  Also if one of the endpoints does not support NACK, then
   some other solution is needed.

   Consequently, the recommendation is that only one piece of minimum
   priority should be present in a compartment at any one time.  If both
   endpoints support NACK [4], then this may be relaxed, but
   implementers should think carefully about the consequences of
   creating multiple pieces of minimum priority state.

   Note that if a compressor wishes the remote endpoint to be able to
   create a new piece of minimum priority state, it can use the
   SIGCOMP-FREE instruction to remove the existing piece of state."

Best regards,

Abbie

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Nov 2004 12:19:52 -0500

Hi Abbie,

two more little wording proposals:

On Nov 05 2004, at 09:18 Uhr, Surtees, Abigail wrote:

> However, for a compressor to try and avoid generating NACKs

s/generating/causing the generation of/

Also, please make sure that in the recommendation paragraph, you again 
say what the presumptions are -- this is bound to be cited out of 
context.

Gruesse, Carsten.