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

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Fri, 17 Dec 2004 22:02:05 +0100

Hi,

See the answers inline ...

br/Zacco

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Gustav E
> Sent: Friday, December 17, 2004 12:41 PM
> To: [email-masked]
> Subject: [rohc] [SigComp]Shared mode and some other 
> SigComp-state related stuff.
> 
> 
> Hi all.
> 
> Since I'm fairly new to this list and SigComp in general, I 
> have a few 
> questions:
> 1. Regarding Shared mode: What became the consensus of the previous 
> discussions on the list? Is the general somewhat simplified 
> recommendation  
> to only "allow" a compressor to create one shared-state?

See the latest implementor's guide.

> 2. State memory: If  compressor A for any reason creates a 
> local state, 
> valid only in one compartment, should the size of that local state be 
> considerad to use any of the available State memory in A? I'm 
> guessing that 
> it should, simply writing the question to be assured.

Yes, it definitely should.

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

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

> 4. General shared-state issue: 3321 states that shared-state is an 
> uncompressed message. Is the recommendation to only use 
> complet uncompressed 
> messages as shared state? What about parts of messages or even other 
> textual-protocol-specific data?

By definition, it is the message itself, unless the state memory of A is known and is smaller than the size of the message + 64, in which case a truncated message will be the shared state.

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

> 
> Appologies for all these questions. Simply hoping to get some sort of 
> clarifications here.
> 
> Best Regards,
> /Gustav E
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 
> _______________________________________________
> 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: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Dec 2004 09:58:18 -0000

Hi Gustav, Zacco,

> See the latest implementor's guide.

The latest version of the implementer's guide is available at
<http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-guide-04.txt>.
It has not been submitted yet and all comments are welcome.  I am intending
to submit it early in January.
 
Best regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 23 Dec 2004 09:59:35 -0000

Hi Ninoo,

The document referred to is the user guide which has currently expired.  It
will be revived early next year.  In the mean time, the last version is
available from
<http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-user-guide-00.txt>.

Best regards,

Abbie

> From: Ninoo Pauls [mailto:[email-masked]] 
> Sent: Thursday, December 23, 2004 9:51 AM
> To: Surtees, Abigail; Lajos Zaccomer (IJ/ETH); Gustav E; [email-masked]
> Subject: RE: [rohc] [SigComp]Shared mode and some other 
> Hi 
>       This document has a para
>    "This document does not address compression specific issues such as
>    different compressor types and bytecode.  This information can be
>    found in a separate document."
> 
>   Can someone give the pointer for the document specified.
> 
> 
> 
> Regards
> Ninoo
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> Surtees, Abigail
> Sent: Monday, December 20, 2004 3:28 PM
> To: 'Lajos Zaccomer (IJ/ETH)'; 'Gustav E'; [email-masked]
> Subject: RE: [rohc] [SigComp]Shared mode and some other SigComp-state
> related stuff.
> 
> Hi Gustav, Zacco,
> 
> <http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-g
uide-04.tx
t>.
It has not been submitted yet and all comments are welcome.  I am
intending
to submit it early in January.
 
Best regards,

Abbie