300 likes | 313 Views
SigComp: Signaling Compression. Andrea G. Forte Department of Computer Science Columbia University. Why Compression?. Text-based protocols (SIP, …) Large messages (INVITE ~ 1200 bytes) Internet Multimedia Subsystem (IMS) Low bit-rate links Delay GSM: About 2 sec. one-way delay (SS7)
E N D
SigComp: Signaling Compression Andrea G. Forte Department of Computer Science Columbia University
Why Compression? • Text-based protocols (SIP, …) • Large messages (INVITE ~ 1200 bytes) • Internet Multimedia Subsystem (IMS) • Low bit-rate links • Delay • GSM: About 2 sec. one-way delay (SS7) • IMS + SIP: Above 6 sec. (more?)
Introduction • Compression • Can be in one direction only • The compression algorithm can differ on each end • Improves with the number of messages exchanged (static dictionary) • SigComp messages • Five most significant bits of a SigComp message are set to 1 • Special prefix which does not occur in UTF-8 • Receive uncompressed messages and SigComp messages on the same port • Compartment • An application-specific grouping of messages that relate to a peer endpoint [RFC 3320] • The application determines when a compartment should be created and or closed • Compartment ID: Uniquely identifies a compartment • State memory and compressor allocated on a per-compartment basis
Application (SIP) Application message + compartment ID Decompressed message Compartment ID Compressor Dispatcher Decompressor Dispatcher Decompressor (UDVM) State Handler Compressor 1 State 1 Compressor 2 State 2 SigComp Layer SigComp message SigComp message Transport Layer (UDP, TCP, …) Architecture
Application Layer • Provides • Message to compress • Compartment identifier • IP address and port number of destination • Receives • Decompressed message • What it does … • Keeps track of which compartment belongs to which application session • It decides when to close a certain compartment (i.e. BYE) • By providing compartment IDs implicitly marks messages as legitimate and grants access to state information
Compressor Dispatcher • Maintains a mapping between compartment IDs and compressors • New compartment ID new compressor • Compartment not needed close compressor • Receives application message and compartment ID • Selects appropriate compressor • Receives compressed message and passes it to the transport layer
Compressor (1/2) • Compresses messages • Use of any compression algorithm • End-point must be able to decompress • Virtual machine for decompression • SigComp message contains bytecode (decompression algorithm) • It must ensure that the destination has enough resource to correctly decompress the SigComp message
0 1 2 3 4 5 6 a b r a c a d a b r a c a d a b Look-ahead buffer Rest of sequence to encode Adaptive dictionary offset = 7, length = 4 Compressor (2/2) • LZ77, LZSS Algorithms • Compression via text substitution • Encountered before in the message?
Decompressor Dispatcher • Receives SigComp message from transport layer • Invokes a new UDVM instance to decompress the message • Initializes the UDVM memory with a previously saved state whose ID is included in the header of the SigComp message just received (this includes the bytecode used for decompression) • Sends decompressed message to application • Applications sends a compartment ID for that message to the decompressor dispatcher • The compartment ID is then forwarded to the state handler which saves state information, content of UDVM memory and any eventual feedback item
UDVM (1/3) • Virtual machine optimized for running decompression algorithms • Executes a program called bytecode on the virtual machine • The header of a SigComp message contains UDVM instructions (bytecode) to instruct the UDVM on how to decompress the received message • Unsecure transport layer • Separate UDVM instances are invoked on a per-message basis • Damaged messages do not affect decompression of subsequent messages • State of a previous UDVM instance can be restored and used by a later UDVM instance for decompression of subsequent messages
UDVM (2/3) • End of message • Dispatcher provides compartment ID • UDVM sends a state creation request containing compartment ID to the state handler • State handler saves state information in the state memory reserved for the corresponding compartment • UDVM cycle (limit) • CPU power required to execute a UDVM instruction • Bytecode containing looping code
UDVM (3/3) • Decompression memory • Typical sizes: 4096, 8192, … bytes • Size is negotiable and can be advertised to the other party (compressor) • Divided in two parts • Store decompressed message • Hold bytecode and a circular buffer used for state
State Handler • A new UDVM instance is invoked on a per-message basis Save information between messages • Messages can be compressed relative to information in previous messages Improved compression ratio • State item (either): UDVM instance’s memory snapshot, uncompressed message • State memory on a per-compartment basis • Ensures that no compartment exceeds its allocated state memory
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1 1 1 1 1 T len 1 1 1 1 1 T 0 returned feedback item returned feedback item partial state identifier code_len code_len destination remaining SigComp message uploaded UDVM bytecode remaining SigComp message SigComp Message • The format of the field remaining SigComp message is an implementation decision and is done by the compressor supplying the UDVM bytecode • RFC 3321 defines a new header in remaining SigComp message in order to support extended operations (no changes required to the protocol) header
Extended Operations • Dynamic compression • Compress current message relatively to previous sent messages (feedback) • Shared compression • Compress current message relatively to previous sent and received messages • State maintained across application sessions • Lifetime of a compartment longer than the duration of an application session • User-specific dictionary • A user-device combination produces the same values for many of the fields contained in a message ( To, Via, …)
Feedback Mechanism (1/2) • Request/Response model • Requested feedback item • Returned feedback item • Feedback items are always piggybacked on SigComp messages • Feedback items are part of the overall state and are associated to a compartment Feedback item needs a valid compartment ID to be saved as state item • Returned feedback item has a size of 1-128 bytes
Feedback Mechanism (2/2) • Feedback can help in having one end-point discover the capabilities of the other end-point • State items available • State_memory_size • Compressor must choose a compression algorithm so that decompressor has all the resource needed for decompression • Successful decompression needs to be acknowledged for unreliable transport (UDP)
Negative Acknowledgment (1/2) • One end-node has an implicit corrupted compartment (failure, loss of connectivity, terminal restart, etc.) • SigComp [RFC 3320] considers all states lost for that end-point (WASTE!) • NACK allows the reporting of error information (decompression failure) between two nodes • The NACK contains information regarding the particular failure • The compressor can use the received information to tweak the compression parameters and prevent other failures
Negative Acknowledgment (2/2) • The compressor calculates a hash value of each SigComp message • If decompression failure happens, the receiver sends a NACK to the compressor • The NACK contains: • Hash of the message whose decompression failed • Exact reason for the failure • Additional details that might help in solving the problem • If NACK received when using reliable transport, SigComp must indicate the error to the application • The application will respond to a normal transport layer error
INVITE UA P-CSCF 100 Trying 183 Session in Progress PRACK 200 OK (PRACK) UPDATE 200 OK (UPDATE) 180 Ringing PRACK 200 OK (PRACK) 200 OK (INVITE) ACK Experiments (1/2)
UA P-CSCF INVITE 100 Trying 180 Ringing 200 OK ACK Experiments (2/2)
Related Work (some) • SigComp: RFC 3320 • Basic mechanism • Extended Operations: RFC 3321 • Dynamic compression • Shared compression • User Specific Dictionary (USD) • Requirements: RFC 3322 • Requirements on SIP: RFC 3486
Thank you! Questions?
Template-based CompressionWhy compression? SIP Chosen as signaling protocol for IMS text-based protocol Average SIP INVITE as large as 1200 bytes IP Multimedia Subsystem (IMS) Low bit-rate links Long call set-up delay Not suitable for PoC Delay GSM: ~ 2 sec one-way delay (SS7) PoC: ~ 1 sec requirement
Template-based CompressionSigComp – Pros and Cons Advantages Already standardized by IETF Mandatory in IMS rel 5 and above Implementations already available Open SigComp (Deflate) Disadvantages Complex and heavy LZ-based compression not good enough for PoC and IMS Overhead UDVM bytecode, feedback item, state identifier, etc.
Template-based CompressionOur approach Templates Send only variable parameters of SIP messages Shared Dictionary (SD) Association between URIs and index in SD Headers affected: From, To, Contact, etc. Association between codecs and indexes in SD Lines affected: m= lines, rtpmap lines, fmtp lines, etc. Other Header Stripping Some SIP headers and SDP lines are irrelevant to the receiver (Via, Max-Forwards, Record Route, etc.) Compression Various compression techniques are used (integer encoding, bit-mask encoding, etc.) Packet Optimization The compressed packet is structured so to minimize its size and the order of the compressed values in the packet is fixed
Template-based Compression Incoming INVITE –Compression SigComp makes things worst !
Template-based CompressionConclusions • Why compression • SIP rich text protocol • Good for high bandwidth • IMS and cellular • low bandwidth • Long call set-up delay • SigComp • Advantages • Already RFC • Mandatory in IMS release 5 and above • Implementations already available (Open SigComp - deflate) • Disadvantages • Not good enough for PoC and IMS • Complex and heavy • Template based compression (TBC) • Templates • SD • Performances • Below 113 bytes for downlink direction • About 30~40 bytes for uplink direction • Satisfies delay requirements for PoC in IMS