SigComp:%20Signaling%20Compression

1
SigComp Signaling Compression

• Andrea G. Forte
• Department of Computer Science
• Columbia University

2
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?)

3
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

4
Architecture
5
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

6
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

7
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

8
Compressor (2/2)

• LZ77, LZSS Algorithms
• Compression via text substitution
• Encountered before in the message?

9
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

10
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

11
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

12
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

13
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 instances memory
  snapshot, uncompressed message
• State memory on a per-compartment basis
• Ensures that no compartment exceeds its allocated
  state memory

14
SigComp Message
header

• 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)

15
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, )

16
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

17
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)

18
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

19
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

20
Experiments (1/2)
21
Experiments (2/2)
22
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

23
Thank you!

• Questions?

24
(No Transcript)
25
Template-based Compression Why 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

26
Template-based Compression SigComp 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.

27
Template-based Compression Our 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

28
Template-based Compression Incoming INVITE
Contributions
New heuristic is added to the previous one Original Size Template Stripped Headers Various (bit-masks, string2int) SD Public IDs Packet Optimization
Size (Bytes) 1182 517 343 196 137 81
Savings (Bytes) - 665 174 147 59 56
Savings () - 56.26 14.72 12.43 5.0 4.73
29
Template-based Compression Incoming INVITE
Compression
Original size SigComp only Template only Template SigComp Template SD Template SD SigComp
Full Flow (Bytes) 1182 592 149 115 81 87
Optimized Flow (Bytes) 1182 658 149 122 81 87
SigComp makes things worst !
30
Template-based Compression Conclusions

• 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