OMA-PAG-2006-0590-INP_PRS2-pres-dict Addressing concerns on Presence Dictionary

© 2006 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document.

OMA-PAG-2006-0590-INP_PRS2-pres-dict Slide #1[OMA-Template-SlideDeck-20060101-I]

Submitted To: PAG

Date: 27 Sep 2006

Availability: Public OMA Confidential

Contact: Krisztian Kiss, [email protected]

Source: Nokia

OMA-PAG-2006-0590-INP_PRS2-pres-dict

Addressing concerns on Presence Dictionary

X

USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT.

THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

Intellectual Property Rights

Members and their Affiliates (collectively, "Members") agree to use their reasonable endeavours to inform timely the Open Mobile Alliance of Essential IPR as they become aware that the Essential IPR is related to the prepared or published Specification. This obligation does not imply an obligation on Members to conduct IPR searches. This duty is contained in the Open Mobile Alliance application form to which each Member's attention is drawn. Members shall submit to the General Manager of Operations of OMA the IPR Statement and the IPR Licensing Declaration. These forms are available from OMA or online at the OMA website at www.openmobilealliance.org.



ABSTRACT

• The initial implementations and studies raised a concern related to the amount of traffic over the air interface in case of mobile terminals accessing the Presence Server.

• This concern has been addressed in both IETF and OMA specifications.

• This presentation will address the comments to Nokia’s paper introduced at the Osaka meeting regarding the usage of SIGCOMP with Static Dictionaries.



Contents

• Introduction• Loading multiple static dictionaries• Dynamic Compression in the mobile environment• User defined dictionaries vs. Static dictionaries



IntroductionLoading multiple static dictionariesDynamic Compression in the mobile environmentUser defined dictionaries vs. Static dictionaries

Contents



Why these slides?

• During the Osaka meeting Nokia introduced a paper about compressing the Presence traffic on the air interface using Static Dictionaries. The paper was noted but delegates needed more time to think about the issue. The following high level comments have been received and this paper is trying to address them.

• Dynamic SigComp offers better results than Static SigComp• If using dictionaries then user Defined Dictionaries are the way to go• If Static Dictionaries were accepted there will be the following Problems:

• Separation of traffic (Presence Traffic separated from non-Presence Traffic)• Different SigComp compartments are needed



Introduction

Loading multiple static dictionariesDynamic Compression in the mobile environmentUser defined dictionaries vs. Static dictionaries

Contents



SigComp with Static Dictionaries• Compressor can compress a message using the state items available at

the decompressor end• Bytecode state item is indicated partial state id in SigComp message format 1• Identifiers for other state items can be included in the bytecode or in the later

message data• Dynamic state items:

• are uploaded by compressor, stored in decompressor end• consume compartment-specific State Memory in decompressor end

• Static state items:• provided by decompressor (but they must be available in both ends)• do not consume compartment-specific State Memory

(one instance is shared by all compartments)• availability can be agreed by other means (e.g., RFC 3485 SIP dictionary state

item, no advertisements needed)• can be advertised by decompressor as specified in RFC 3320



Static Dictionaries - ISSUES• Using extra dictionaries waste memory and CPU cycles. How we can separate traffic and

use the application-specific dictionary only with the application in question?• There is no standard way for a compressor to distinguish which dictionaries should be

used, but it can be done based on the message contents itself.• E.g., a presence message will contain the “Event: presence” header field. It can be

detected using regular expression /(event|o) LWS * : LWS* presence (;|CRLF)/ covering different forms for the header. A dictionary containing the presence terms will be used only when a regexp match is found in the message headers.

• How to load the needed and only the needed dictionaries for decompression?• Compressed message can contain a header indicating required dictionaries.

Future slides describe a way of doing this using single bytecode• 3GPP mandates the use of only one SigComp compartment.

Can one SigComp compartment handle the scenario with multiple dictionaries and multiple state items?

• Yes, it can.Sigcomp bytecode accesses dictionaries with STATE-ACCESS instruction. There is no fixed limit on the number of STATE-ACCESS instructions executed.



Loading the Static Dictionaries:Header in Compressed Message

1 dict_info_size 1 1

CompressedMessage

Bitsdict_info_size

dict_info dict_info

• The compressed message starts with a header that conveys the static dictionary ids to be loaded

• The format of the header is depicted in the figure below:



Loading the Static Dictionaries:Assembly for SigComp bytecode

… Variable initializations …

:load_all_staticINPUT-BITS(1, static_dict, !)SWITCH(2, $static_dict, load_static_dict, continue_decompression):load_static_dictINPUT-BITS(4, id_len, !)ADD($id_len, 6)INPUT-BITS(11, dict_len, !)INPUT-BYTES($id_len, dict_id, !)STATE-ACCESS(dict_id, $id_len, 0, $dict_len, $circular_buffer, 0); advance $circular_buffer by $dict_lenCOPY-OFFSET(0, $dict_len, $circular_buffer)JUMP(load_all_static):continue_decompression

1 0dict_info dict_info1



IntroductionLoading multiple static dictionaries

Dynamic vs. Static Compression in the Mobile Environment

User defined dictionaries vs. Static dictionaries

Contents



Dynamic Compression

• SigComp messages are compressed based on previously sent messages. • Messages are saved as states in the remote end point to be used later. • When using Dynamic compression the Compressor gains knowledge about

the reception of the messages through feedback items sent by decompressor

• Dynamic compression get best performance when each application session gets its own compartment

• With reliable transport, state memory size should be at least half of the decompression memory for best performance

• 8 K DMS => 4 K SMS• With unreliable transport like UDP, state memory size should be a multiple

of decompression memory for best performance• 8 K DMS => 32 K SMS



Dynamic Compression – IETF Example

Saved Acknowledged | | Saved

State(s) State(s) | | State(s)

------------------------------------------------------------------------

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

s0 s0 s0

s1=m1+s0 s0 -----m1(s0)-----> s0

<------ack s1----- s0,s1

s0,s1 s0,s1 s0,s1

s2=m2+s1 s0,s1 -----m2(s1)-----> m2 lost

S3=m3+s1 s0, s1 -----m3(s1)-----> s0,s1

<-----ack s3----- s0,s1,s3

s0,s1,s3 s0,s1,s3 s0,s1,s3



Dynamic Compression in Practice

Saved

State(s)

Saved

State(s)

Acknowledged

State(s)

State MemoryState Memorys0 s0

s0

s1=m1+s0

ack s1

State Memorys0 s1=m1+s0

s2=m2+s1 s2=m2+s1State Memory

s0 s2=m2+s1

s1=m1+s0

State Memorys0 s1=m1+s0 s0 s1=m1+s0

s3=m3+s1 s3=m3+s1

s3=m4+s0 s3=m4+s0 State Memorys0 s3=m4+s0

ack s3s0 s3=m4+s0

Compression Failure

Ack lost



State Memory

Dynamic Compression in Presence Context

Compressor - UE

Decompressor – P-CSCF

User Info

Register

200 OKUser Info

Invite

200 OK

SDP Info

SDP Info

Publish

200 OK

Presence

Presence

State Memory

User Info

Re - Register

200 OKUser Info



Dynamic Compression (DC) - ISSUES• The State Memory Size affects the amount of dynamic information that a Compressor

can store in the remote end. In practice, when the available State Memory is not enough the older states are removed in which case they need to be uploaded again. In the worst case a state uploaded on the Decompressor side “does not live” long enough to be used for the subsequent message that might gain advantage from using it.

• The dynamic states uploaded to the Decompressor side must be kept in sync. In particular the states that the Compressor is using must be available for the Decompressor. An unreliable network in which messages are lost will cause the State Memory to go out of sync. The Compressor have to upload initial state again or risk using states that are no longer available.

• As multiple SIP applications are used, DC is not always that effective. Consider the case when a Presence message is compressed after a SIP INVITE. Using PD for a presence message should provide better compression than using a previous non-Presence message.

• Keeping dynamic state requires lots of memory on server side. In order to store state, compressor requires 3 to 6 times more memory as decompressor. 2 K dynamic state implies at least 6 K of compression state, which translates to 60 GB of RAM with 10 million subscribers. Some memory can be saved by recreating the compression state from saved state items but it requires more CPU processing power and increases latency.



Static Compression• Static Compression = The messages are compressed using states locally stored in both

Ends. • Locally stored states are agreed between the parties involved in compression.• Locally stored states can be widely known (common dictionaries for a common protocols) or

they can be advertised whenever supported.• Locally stored states do neither consume State Memory nor the radio resource.• For small messages (like Partial Notification where there is not much repetition), pure

DEFLATE may not be that effective. A static Presence Dictionary can be still effective in this situation.

• Locally stored dictionaries can be loaded partially into decompression memory to make efficient use of memory. Defining a dictionary intelligently (e.g. most common phrases at the end) would allow gaining most, even if a dictionary is loaded partially.

• Combined static and dynamic compression:When static memory size (default 2K) is small compared to decompression memory size (default is 8K), the otherwise empty ring buffer (6K or even more) can be filled by static dictionaries



Static Compression – Presence Dictionary

Compressor - UE Decompressor – P-CSCF

Message

Compressor

SigComp Msg. Send

State Memory

User Info

SDP Info

Memory SigComp Msg.

State Memory

User Info

SDP Info

Load

UDVM

User Info

SDP Info

Load

Presence Dictionary Presence Dictionary

Presence Dictionary

Load

Load



Introduction

Loading multiple static dictionaries

Dynamic vs. Static Compression in the mobile environment

User defined dictionaries vs. Static dictionaries

Contents



User Specific Dictionary

• A User Specific Dictionary (USD) is a collection of words and phrases containing the most used tokens by a specific user in messages to be sent.

• A User Specific Dictionary is uploaded onto the Decompressor side by the Compressor as part of the first message – On the air interface a User Specific Dictionary is uploaded whenever a compartment is created. A Static Dictionary is never sent over the air interface.

• A User Specific Dictionary is stored as a State in the State Memory – The State Memory is used and there may no space left for other states. Moreover, should the Compressor upload a new State there is the risk to lose the User Specific Dictionary hence the need to upload it again on the air interface.

• Each user has her own User Specific Dictionary is stored in Server Side – State Memory on the Server Side must be carefully considered. Consider a server handling 10,000,000 users. If each of them was to store a 2KB User Specific Dictionary there will be 20 GB of extra state memory to handle. A Static Dictionary is stored as one single instance - it consumes 2 KB of memory even if all the 10,000,000 users use it.

• A User Specific Dictionary is loaded by the Compressor into its Circular Buffer – One of the arguments against the Static Dictionary was exactly the fact that it is loaded in the Circular Buffer hence leaving less memory for the actual compression. WHAT IS THE DIFFERENCE WHEN LOADING THE USER SPECIFIC DICTIONARY? The difference in size is not a valid argument since a “smart” compressor can load only the essential part of a static dictionary.

• A user specific dictionary requires very careful design to make it effective when the traffic is asymmetric.



Conclusion

• Presence dictionary improves performance with static compression dramatically• Helps compressing relatively small presence messages• Works even when dynamic compression or USD is too expensive

• Network with large number of subscribers => single compartment, small SMS• E.g., 3GPP IMS

• Improves performance with dynamic compression• when decompression memory size is larger than usable state memory size• when multiple applications use same compartment

(3GPP mandates only one compartment)• Complements and enhances USD

• Common presence phrases can be left out of USD

Documents

OMA-PAG-2006-0590-INP_PRS2-pres-dict Addressing concerns on Presence Dictionary