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

OMA-PAG-2006-0590-INP_PRS2-pres-dict Addressing concerns on Presence Dictionary Submitted To: PAG Date: 27 Sep 2006 Availability: Public OMA Confidential Contact: Krisztian Kiss, krisztian.kiss@nokia.com Source: Nokia 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

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

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

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 • 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: Compressed Message dict_info dict_info 1 1 1 dict_info_size dict_info_size Bits

Loading the Static Dictionaries:Assembly for SigComp bytecode dict_info dict_info 0 1 1 … Variable initializations … :load_all_static INPUT-BITS(1, static_dict, !) SWITCH(2, $static_dict, load_static_dict, continue_decompression) :load_static_dict INPUT-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_len COPY-OFFSET(0, $dict_len, $circular_buffer) JUMP(load_all_static) :continue_decompression

Contents • Introduction • Loading multiple static dictionaries • Dynamic vs. Static Compression in the Mobile Environment • User defined dictionaries vs. Static dictionaries

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

State Memory State Memory s0 s0 s0 State Memory s1=m1+s0 s0 s1=m1+s0 ack s1 State Memory s0 s1=m1+s0 s0 s1=m1+s0 State Memory s2=m2+s1 s0 s2=m2+s1 Ack lost s3=m3+s1 Compression Failure State Memory s3=m4+s0 s0 s3=m4+s0 s0 s3=m4+s0 ack s3 Dynamic Compression in Practice Saved State(s) Acknowledged State(s) Saved State(s) s1=m1+s0 s2=m2+s1 s3=m3+s1 s3=m4+s0

State Memory Register 200 OK User Info User Info Invite 200 OK SDP Info Publish 200 OK Presence Re - Register 200 OK User Info Dynamic Compression in Presence Context Compressor - UE Decompressor – P-CSCF State Memory Presence User Info SDP 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

SDP Info Presence Dictionary Load User Info Send Load Load Load Static Compression – Presence Dictionary Compressor - UE Decompressor – P-CSCF Message Memory SigComp Msg. UDVM Compressor SigComp Msg. State Memory State Memory User Info SDP Info SDP Info User Info Presence Dictionary Presence Dictionary

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

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

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