Signaling Compression (SigComp)
updated by
- rfc-4896 — Signaling Compression (SigComp) Corrections and Clarifications
Extracted elements (32)
SigComp messages are identified by five high-order bits of the first byte all set to 1, a pattern that cannot appear in UTF-8 or ASCII encoded text. This allows uncompressed and SigComp-compressed messages to be multiplexed on the same transport port.
State memory cost is calculated as (state_length + 64) bytes per item, where the 64-byte overhead accounts for the fixed-size metadata fields (state_identifier, state_length, state_address, state_instruction, minimum_access_length) stored alongside each state value.
The locally available state_retention_priority of 65535 is reserved exclusively for locally available state items, ensuring they are always freed before application-created state when compartment memory is exhausted, preventing local state from interfering with remotely requested state.
The UDVM was created to decouple decompression algorithm choice from the protocol: rather than negotiating one of a small set of pre-defined algorithms, any algorithm can be used by uploading its decompression bytecode within the SigComp message. Typical decompression bytecode is sub-100 bytes.
SigComp version backward compatibility is guaranteed: a message that decompresses successfully on Version 0x01 will continue to decompress on upgraded versions. Upgraded versions may add UDVM instructions without affecting v0x01-compatible messages. Reserved UDVM memory addresses (10–31) may be assigned in future versions.
All endpoints implementing SigComp MUST offer a decompression_memory_size of at least 2048 bytes and MUST offer a minimum of 16 cycles_per_bit. Endpoints MAY offer additional resources, which can be advertised via the SigComp feedback mechanism.
Any UDVM memory addresses not yet initialized MUST be set to 0; however a decompressor MUST NOT rely on reserved addresses 10–31 being zero, as future SigComp versions may assign Useful Values there.
If a byte-copying operation overwrites the instruction that invoked it (or overwrites byte_copy_left/byte_copy_right), the copy MUST be completed as if the original instruction were still in place.
If a compression failure occurs the dispatcher MUST report the failure to the application so that it can try other methods to deliver the message.
The compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint. For message-based transport the compressor MUST map each application message to exactly one SigComp message.
The compressor MUST NOT send bytecode which causes the UDVM to incorrectly decompress a given SigComp message. Transparency is the overriding requirement on the compressor.
The decompressor dispatcher MUST NOT make more than one SigComp message available to a given instance of the UDVM; in particular, it MUST NOT concatenate two SigComp messages to form a single message.
The number of UDVM cycles MUST NOT be increased if a request for additional compressed data fails, preventing exploitation of failed INPUT instructions to gain extra processing budget.
The state handler MUST reject all state creation requests not accompanied by a valid compartment identifier, or when the compartment is allocated 0 bytes of state memory.
A compartment is an application-specific grouping of messages relating to a peer endpoint, corresponding to concepts such as 'session', 'dialog', or 'association'. SigComp allocates a separate compressor and a fixed amount of state memory per compartment.
Each state item contains: a 20-byte state_identifier (hash of state content), a 2-byte state_length, 2-byte state_address, 2-byte state_instruction, a 2-byte minimum_access_length (6–20), and a state_value byte string of state_length bytes.
SigComp endpoint capabilities are described by five parameters: decompression_memory_size, state_memory_size, cycles_per_bit, SigComp_version, and a set of locally available state items. Each has a mandatory minimum value.
The SigComp feedback mechanism allows a compressor to piggyback a feedback request onto a message; the remote UDVM forwards the data via the state handler to the appropriate peer compressor, which returns it piggybacked on a subsequent SigComp message.
The UDVM has four 2-byte registers stored MSB-first: byte_copy_left (addr 64–65), byte_copy_right (addr 66–67), input_bit_order (addr 68–69), and stack_location (addr 70–71).
The UDVM instruction set comprises 36 instructions (bytecodes 0–35) covering arithmetic/logical operations, memory operations, stack (PUSH/POP/CALL/RETURN), byte copying, I/O (INPUT-BITS, INPUT-HUFFMAN, INPUT-BYTES), hashing (SHA-1, CRC), state access/creation/free, OUTPUT, and END-MESSAGE.
Section 11 contains IANA considerations for SigComp. The SigComp_version parameter space (currently version 0x01) and UDVM instruction bytecode space (currently 36 instructions, bytecodes 0–35) are defined in this document and subject to IANA registration for future extensions.
A separate UDVM instance is invoked for each received SigComp message, ensuring that a corrupted or malicious message cannot interfere with the decompression of other messages or corrupt shared state.
New state can only be created with the explicit permission of the application (via a returned compartment identifier), preventing malicious SigComp messages from injecting state into a remote endpoint's state store.
State access is protected by requiring the requester to supply a state_identifier that is a cryptographic hash of the state item itself. The minimum_access_length (6–20 bytes) provides a configurable lower bound on the identifier prefix that must be presented, preventing brute-force guessing.
UDVM cycle budget limits processing per message via: maximum_UDVM_cycles = (8 × n + 1000) × cycles_per_bit, where n is message size in bytes. This prevents denial-of-service through computationally expensive decompression algorithms.
A SigComp message starts with a byte whose five MSBs are all 1. Bit 5 (T-bit) indicates presence of a returned feedback item. Bits 6–7 (len) are non-zero when a partial state identifier follows; zero when UDVM bytecode is uploaded inline.
For stream-based transports, record marking escapes 0xFF: 0xFF00 = one literal 0xFF; 0xFF01–0xFF7F = quote 1–127 following bytes verbatim; 0xFF80–0xFFFE = reserved (causes decompression failure); 0xFFFF = end of SigComp message.
SigComp parameters are compactly encoded for the feedback mechanism: cycles_per_bit uses 2 bits (00=16, 01=32, 10=64, 11=128); decompression_memory_size and state_memory_size each use 3 bits (000=0 bytes up to 111=131072 bytes, with 000 invalid for decompression_memory_size).
The first 32 bytes of UDVM memory (Useful Values) are initialized at startup: 0–1 = UDVM_memory_size, 2–3 = cycles_per_bit, 4–5 = SigComp_version, 6–7 = partial_state_ID_length, 8–9 = state_length, 10–31 = reserved (zero in version 0x01).
The returned feedback item is 1 byte when MSB=0 (7-bit inline value), or 1 length byte (MSB=1, 0–127) followed by that many bytes of returned_feedback_field, for a total of 1–128 bytes.
UDVM operands use four variable-length encodings: literal (#, 1–3 bytes for 0–65535), reference ($ always yields a 2-byte memory value), multitype (% with 10 bytecode patterns covering direct values, memory addresses, and powers of 2), and address (@ decoded as multitype plus instruction-relative offset).
When the SigComp message len field is zero, a 12-bit code_len field specifies the uploaded UDVM bytecode size (0–4095 bytes), and a 4-bit destination field encodes the load address as destination × 64 (valid values 0001–1111; 0000 is reserved and causes decompression failure).