OMA-PAG-2006-0590-INP_PRS2-pres-dict
Addressing concerns on Presence
Dictionary
Submitted To: PAG
Date: 27 Sep 2006
Availability: X Public
OMA Confidential
Contact: Krisztian Kiss, krisztian.kiss@nokia.com
Source: Nokia
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.
© 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]
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.
© 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]
Contents
•
•
•
•
Introduction
Loading multiple static dictionaries
Dynamic Compression in the mobile environment
User defined dictionaries vs. Static dictionaries
© 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
© 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]
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
© 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]
Contents
Introduction
Loading multiple static dictionaries
Dynamic Compression in the mobile environment
User defined dictionaries vs. Static dictionaries
© 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]
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
•
© 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]
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.
© 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]
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
Bits
dict_info
1
dict_info_size
© 2006 Open Mobile Alliance Ltd. All Rights Reserved.
dict_info
1
dict_info_size
Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document.
1
OMA-PAG-2006-0590-INP_PRS2-pres-dict
Slide #9
[OMA-Template-SlideDeck-20060101-I]
Loading the Static Dictionaries:
Assembly for SigComp bytecode
1
dict_info
1
dict_info
0
… 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
© 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]
Contents
Introduction
Loading multiple static dictionaries
Dynamic vs. Static Compression in the
Mobile Environment
User defined dictionaries vs. Static dictionaries
© 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]
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
© 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 – IETF Example
Saved
State(s)
Acknowledged
|
|
Saved
State(s)
|
|
State(s)
------------------------------------------------------------------------
s0
s1=m1+s0
s0,s1
s0
|
|
s0
s0
|
|
s0
s0,s1
s2=m2+s1
s0,s1
S3=m3+s1
s0, s1
|
<------ack s1----- |
|
|
|
|
|
|
|
s0,s1,s3
-----m2(s1)----->
-----m3(s1)----->
<-----ack s3-----
|
|
© 2006 Open Mobile Alliance Ltd. All Rights Reserved.
|
|
|
s0,s1,s3
-----m1(s0)----->
Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document.
|
|
|
s0,s1
s0,s1
m2 lost
s0,s1
|
s0,s1,s3
|
s0,s1,s3
|
OMA-PAG-2006-0590-INP_PRS2-pres-dict
Slide #13
[OMA-Template-SlideDeck-20060101-I]
Dynamic Compression in Practice
Saved
Acknowledged
Saved
State(s)
State(s)
State(s)
State Memory
s0
State Memory
s0
s0
s1=m1+s0
s1=m1+s0
ack s1
State Memory
s0
s1=m1+s0
s0
State Memory
s0
s1=m1+s0
s1=m1+s0
s2=m2+s1
State Memory
s0
s2=m2+s1
s3=m3+s1
s3=m3+s1
Compression Failure
s3=m4+s0
s3=m4+s0
State Memory
s0
s3=m4+s0
s2=m2+s1
Ack lost
s0
s3=m4+s0
© 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.
ack s3
OMA-PAG-2006-0590-INP_PRS2-pres-dict
Slide #14
[OMA-Template-SlideDeck-20060101-I]
Dynamic Compression in Presence Context
Compressor UE
Decompressor – P-CSCF
State Memory
Register
200 OK
Invite
User
Info
200 OK
SDP Info
Publish
Presence
SDP Info
User Info
200 OK
Presence
Re - Register
200 OK
User
Info
© 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]
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 nonPresence 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.
© 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]
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
© 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 – Presence Dictionary
Decompressor – P-CSCF
Compressor - UE
Message
Memory
UDVM
Compressor
Load
SigComp Msg.
SigComp Msg.
Presence
Dictionary
Send
SDP Info
User
Info
State Memory
User
Info
SDP Info
Load
State
Memory
User
Info
Load
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.
SDP Info
Load
Presence Dictionary
OMA-PAG-2006-0590-INP_PRS2-pres-dict
Slide #18
[OMA-Template-SlideDeck-20060101-I]
Contents
Introduction
Loading multiple static dictionaries
Dynamic vs. Static Compression in the mobile environment
User defined dictionaries vs. Static
dictionaries
© 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]
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.
© 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]
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
© 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]