Subject: RE: [rohc] Shared mode

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Fri, 5 Nov 2004 16:33:19 +0100

Hi Abbie,

It's quite OK for me, but I'd really like to have something about the possible specific relation to the higher layer protocol some features of it may pose less constraints for implementors. One example was given in my previous mail. Neither POC nor SIP should be mentioned in the guide, of course, only a general message sequence just as you did with a short explanation. Is this all right?

Best regards,

Zacco

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