1 / 30

SigComp: Signaling Compression

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)

theodoreburns
Download Presentation

SigComp: Signaling Compression

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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

  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. 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?

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

  14. 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

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

  21. UA P-CSCF INVITE 100 Trying 180 Ringing 200 OK ACK 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. 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

  25. 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.

  26. 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

  27. Template-based Compression Incoming INVITE –Contributions

  28. Template-based Compression Incoming INVITE –Compression SigComp makes things worst !

  29. 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

More Related