1. SigComp: Signaling Compression
Andrea G. Forte
Department of Computer Science
Columbia University
11/20/2018

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 SigComp messages Compartment
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. Transport Layer (UDP, TCP, …)
Architecture
Application (SIP)
Transport Layer (UDP, TCP, …)
Compressor
Dispatcher
Compressor 1
Compressor 2
State Handler
State 1
State 2
Decompressor
(UDVM)
SigComp Layer
SigComp message
Application message
+ compartment ID
Decompressed
message
Compartment ID

5. Application Layer Provides Receives What it does … 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? a b r c d
Adaptive dictionary
Look-ahead buffer
Rest of sequence to encode
offset = 7, length = 4

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 UDVM cycle (limit)
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. SigComp Message
returned feedback item
partial state identifier
remaining SigComp message
len 1 T 2 3 4 5 6 7
returned feedback item
uploaded UDVM bytecode
remaining SigComp message 1 T
code_len
destination 2 3 4 5 6 7
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 Shared 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 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) UA P-CSCF INVITE 100 Trying 183 Session in Progress
ACK
200 OK (INVITE)
200 OK (PRACK)
PRACK
180 Ringing
200 OK (UPDATE)
UPDATE
183 Session in Progress
100 Trying
INVITE UA
P-CSCF

21. Experiments (2/2)
P-CSCF
INVITE
100 Trying
180 Ringing
200 OK
ACK UA

22. Related Work (some) SigComp: RFC 3320 Extended Operations: RFC 3321
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?

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 25

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

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 27

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 + SD
Full Flow
(Bytes)
1182
592
149
115 81 87
Optimized Flow
658
122
SigComp makes things worst ! 29

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
About 30~40 bytes for uplink direction
Satisfies delay requirements for PoC in IMS