1. © 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, krisztian.kiss@nokia.comkrisztian.kiss@nokia.com 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.http://www.openmobilealliance.org/UseAgreement.html 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.

2. © 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 #2 [OMA-Template-SlideDeck-20060101-I] 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.

3. © 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 #3 [OMA-Template-SlideDeck-20060101-I] Contents Introduction Loading multiple static dictionaries Dynamic Compression in the mobile environment User defined dictionaries vs. Static dictionaries

4. © 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 #4 [OMA-Template-SlideDeck-20060101-I] Introduction Loading multiple static dictionaries Dynamic Compression in the mobile environment User defined dictionaries vs. Static dictionaries Contents

5. © 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 #5 [OMA-Template-SlideDeck-20060101-I] 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

6. © 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 #6 [OMA-Template-SlideDeck-20060101-I] Introduction Loading multiple static dictionaries Dynamic Compression in the mobile environment User defined dictionaries vs. Static dictionaries Contents

7. © 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 #7 [OMA-Template-SlideDeck-20060101-I] 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

8. © 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 #8 [OMA-Template-SlideDeck-20060101-I] 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.

9. © 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 #9 [OMA-Template-SlideDeck-20060101-I] Loading the Static Dictionaries: Header in Compressed Message 1 dict_info_size 11 Compressed Message Bits dict_info_size 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:

10. © 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 #10 [OMA-Template-SlideDeck-20060101-I] Loading the Static Dictionaries: Assembly for SigComp bytecode … 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 1 0 dict_info 1

11. © 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 #11 [OMA-Template-SlideDeck-20060101-I] Introduction Loading multiple static dictionaries Dynamic vs. Static Compression in the Mobile Environment User defined dictionaries vs. Static dictionaries Contents

12. © 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 #12 [OMA-Template-SlideDeck-20060101-I] 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

13. © 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 #13 [OMA-Template-SlideDeck-20060101-I] 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

14. © 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 #14 [OMA-Template-SlideDeck-20060101-I] Dynamic Compression in Practice Saved State(s) Saved State(s) Acknowledged State(s) State Memory s0 s1=m1+s0ack s1 State Memory s0s1=m1+s0 s2=m2+s1 State Memory s0s2=m2+s1 s1=m1+s0 State Memory s0s1=m1+s0 s0s1=m1+s0 s3=m3+s1 s3=m4+s0 State Memory s0s3=m4+s0 ack s3s0s3=m4+s0 Compression Failure Ack lost

15. © 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 #15 [OMA-Template-SlideDeck-20060101-I] State Memory Dynamic Compression in Presence Context Compressor - UE Decompressor – P-CSCF User Info Register 200 OK User Info Invite 200 OK SDP Info Publish 200 OK Presence State Memory User Info Re - Register 200 OK User Info

16. © 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 #16 [OMA-Template-SlideDeck-20060101-I] 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.

17. © 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 #17 [OMA-Template-SlideDeck-20060101-I] 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

18. © 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 #18 [OMA-Template-SlideDeck-20060101-I] 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 Load

19. © 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 #19 [OMA-Template-SlideDeck-20060101-I] Introduction Loading multiple static dictionaries Dynamic vs. Static Compression in the mobile environment User defined dictionaries vs. Static dictionaries Contents

20. © 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 #20 [OMA-Template-SlideDeck-20060101-I] 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.

21. © 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 #21 [OMA-Template-SlideDeck-20060101-I] 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