Subject: RE: [rohc] Shared mode

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Tue, 9 Nov 2004 07:50:28 +0100

Hi Abbie,

Nice sentence, I like it! :-) If one really needs it, they would probably not miss the message flow.

br/Zacco

> -----Original Message-----
> From: Surtees, Abigail [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 5:31 PM
> To: Lajos Zaccomer (IJ/ETH); [email-masked]
> Subject: RE: [rohc] Shared mode
> 
> 
> Hi Zacco,
> 
> Without specifying a particular application protocol 
> behaviour (which I
> agree we shouldn't do), I'm not sure that the bytecode 
> storage example will
> help.  This is because in a lot of scenarios where it could 
> be safe, I think
> it's possible to construct a similar scenario where there is 
> a problem.
> Consequently, I feel that adding another message flow may add 
> confusion.
> 
> For example, with 2K SMS and appropriate sizes of SM1, SM2 
> and BC (e.g. 900
> bytes, 800 bytes and 500 bytes respectively):
> 
> [SM1]
> 	-----------------------------> 
> 						[SM1]
> 
> <-----response sent uncomp/no state created--
> 
> 
> [SM1, SM2]
> 	------------------------>lost
> 						
> 						[SM1, BC]
> 	<-------------ref SM1------------
> [SM2, BC]
> 
> 						[SM1, BC]
> 	<-------------ref SM1----------					
> State access failure
> 
> We could add the sentence '(In cases where the behaviour of 
> the application
> restricts the message flow, this could be exploited to allow 
> safe creation
> of multiple minimum priority states; however, care must still 
> be taken.)' to
> the end of the recommendation paragraph.
> 
> What do you think?
> 
> Best regards,
> 
> Abbie
> 
> > -----Original Message-----
> > From: Lajos Zaccomer (IJ/ETH) [mailto:[email-masked]] 
> > Sent: Friday, November 05, 2004 3:33 PM
> > To: Surtees, Abigail; [email-masked]
> > Subject: RE: [rohc] Shared mode
> > 
> > 
> > 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.
> > > 
> > 
> 
> -- 
> 
> 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