Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state rela ted stuff.

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 13 Jan 2005 14:11:34 -0000

Hi Zacco, 

Sorry for the delay.  I've got some questions about the PoC related use of
usds.

> 
> > 3. USD. I fully understand the usage of a USD. However, I do 
> > not understand 
> > if a USD-state should be treated any differenty then any 
> > other state created 
> > at the remote end. Is a USD per definition a shared state? 
> 
> No, it isn't. RFC 3321 says it's a regular state. POC USD is 
> something different. I would say it's a regular and a shared 
> state at the same time.

What does that actually mean?  As you say 3321 says it's a regular state, so
in SigComp terms how can it be a shared state as well?

> 
> > I'm guessing that 
> > it must be if the sending compressor is to have any 
> advantage of the 
> > USD-state at the remote end. Then, again, should the 
> > USD-state (local state) 
> > at A be considered to occupy State-memory? Should it be 
> > considered any 
> > differently then any other shared state?
> 
> It depends on which USD you are talking about. A regular 
> state is not saved in a state memory at the compressor side, 
> so if you go for the RFC 3321 USD, it decreases the available 
> memory at B in the state memory of compresssor at A. In case 
> POC USD is used, it must be saved as a local state, otherwise 
> the compressor at B would not be able to access it.

However, we believe that the POC definition of using USD as shared state is
not well defined and can lead to loss of synchronisation between the two
endpoints.

When you say it must be saved as 'local state', do you mean in the state
memory of the compressor at B or not in a compartment at all?
> 
> > 5. (Little bit off-topic, PoC specific question): In the PoC 
> > NEMS Signalling 
> > Spec. "Signalling flows (UNI) v2.06", a procedure for 
> > establishing a USD is 
> > described. Among others it states that the four first bytes of the 
> > state-value should be "usd1". Can any helpful individual 
> > explain to me what 
> > the purpose might be? Should either local or remote 
> endpoint take any 
> > specific action here?
> > The spec says:
> > "For USD identification it is important that the identifier 
> > string is placed 
> > in the beginning of the state_value of the USD, therefore 
> > special attention 
> > must be paid in the case of large USD as the UDVM has a 
> > circular buffer."
> > I do not understand the purpose here..
> 
> Suppose Endpoint 2 supports USD (without the optional 
> requirement of moving it to the local state location) and the 
> explicit acknowledgement specified in RFC 3321, too. If 
> Endpoint 2 explicitlly acks the uploaded USD state ID, 
> Endpoint 1 will think USD is moved to the local states 
> location (indication is the same as if it was an explicit 
> ack) and will not update (decrease) its remote available SMS. 
> Later on it may result in decompression failure if a state is 
> saved deleting another one in use, due to the remote 
> available SMS out of synchron.
> 

I'm a bit confused here:

By 'moving it to the local state location' I take it that you mean that the
state created at Endpoint 2's decompressor would be moved to Endpoint 2's
compressor.  Is this correct?  Would it be duplicated (i.e. still exist in
the decompressor) or actually moved (and therefore the compressor at A has
no control over or knowledge of when it is deleted)?

Are you saying that the presence of the string "usd1" is an indicator to
endpoint 2 that it should move/copy the state into the compressor
compartment?

If so, this seems to be at odds with the SigComp conceptual model of state
that it is just 'some bytes'.  

If my understanding above is correct, then the piece of state presumably has
minimum retention priority?  Care must once again be taken due to the
possibility that the creation of multiple pieces of minimum retention
priority state can lead to loss of synchronisation between endpoints.

How does this mechanism interact with the use of shared mode as defined in
3321?

I also think there are some implications for interoperability between
endpoints that do this and endpoints that don't.  As you showed in your
example above, if there is disagreement between endpoints about whether or
not state is moved to 'local state location' (whatever that is) it can lead
to loss of synchronisation between endpoints.

Is this concept mandatory in PoC?  If not, or if a non PoC endpoint receives
a state create request and an explicit advertisement, it will not know that
it should check the first 4 bytes for "usd1" and move the state so
synchronisation will be lost as you explained.

Best regards,

Abbie

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

---

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Mon, 17 Jan 2005 09:32:31 +0100

Hi Abbie,

See inline ...

br/Zacco

> -----Original Message-----
> From: Surtees, Abigail [mailto:[email-masked]]
> Sent: Thursday, January 13, 2005 3:12 PM
> To: Lajos Zaccomer (IJ/ETH); 'Gustav E'; [email-masked]
> Subject: RE: [rohc] [SigComp]Shared mode and some other 
> SigComp-state rela ted stuff.
> 
> 
> Hi Zacco, 
> 

[zacco] In PoC, the terminal uploads the USD after saving it in the state memory. The special advertisement lets the server know it received a USD that it also saves in the state memory (or outside the state memory, which must be signalled backwards). Thus, both endpoints will have the USD and can use it for compression. That is why I say PoC USD is a dynamic (or regular) and shared state at the same time.

> memory of the compressor at B or not in a compartment at all?

Not in a compartment at all (in A). However, in B it is up to the endpoint if it saves in the state memory or not in the compartment.

> no control over or knowledge of when it is deleted)?
It is not duplicated. I meant it was moved to the "non-compartment" state memory. It must be remembered somehow (implementation stuff) that the state actually belongs to a specific compartment, so when the compartment is deleted, the USD must also be deleted.

> endpoint 2 that it should move/copy the state into the compressor

Besides the state is saved and advertised at the same time. The reason why the usd tag was added is that this situation might easily happen with a well-known bytecode.

> that it is just 'some bytes'.  

Why do you say that? 'usd1' is not something that appears at the beginning of a state, especially in a first message, and especially not in a bytecode.

> priority state can lead to loss of synchronisation between endpoints.

USD is just one state, which is absolutely in line with the "one shared state at a time" concept.

> How does this mechanism interact with the use of shared mode 

Nothing special, as the shared state is not saved as a state in B, only in A. 

> synchronisation will be lost as you explained.

As far as I know it is mandatory, but this I should check.

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