RFC 3322

Signaling Compression (SigComp) Requirements & Assumptions

📅 published January 2003, from ietf

RFC 3322: Signaling Compression (SigComp) Requirements & Assumptions 💖

okay bestie, first things first 🎀 this doc is RFC 3322, and it's called Signaling Compression (SigComp) Requirements & Assumptions. It came from the Network Working Group, and the author is H. Hannu from Ericsson 💅. It's dated January 2003, and its category is Informational 🌸. The title block doesn't say it obsoletes or updates anything, so it's just vibing on its own ✨

Status of this Memo 📚

tbh this memo is just here to give the internet community some info 🦋 it is NOT an Internet standard of any kind. you can share it as much as you want, because distribution is unlimited 🫶

the Internet Society owns the copyright here 🔒 Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🌸

so the whole point of this doc is to lay out the requirements and motivations for building a way to compress and decompress messages from signaling protocols 🧚 in wireless environments, especially cellular systems like GSM (Global System for Mobile communications) and UMTS (Universal Mobile Telecommunications System), we really need to squeeze out every bit of transport efficiency for data over the radio interface 😭 now that SIP/SDP (Session Initiation Protocol/Session Description Protocol) is showing up on cellular devices, compressing those signaling messages should be considered 💜 the goal is better service availability and quality, mainly by cutting the user idle time, like at call setup ✨

Table of Contents 🍓

1.  Introduction....................................................2
1.1.  Protocol Characteristics......................................2
1.2.  Cellular System Radio Characteristics.........................3
2.  Motivation for Signaling Reduction..............................4
2.1.  Estimation of Call Setup Delay Using SIP/SDP..................4
3.  Alternatives for Signaling Reduction............................6
4.  Assumptions.....................................................7
5.  Requirements....................................................8
5.1.  General Requirements..........................................8
5.2.  Performance Requirements......................................9
6. Security Considerations.........................................11
7. IANA Considerations.............................................11
8. References......................................................11
9. Author's Address................................................12
10. Full Copyright Statement.......................................13

1. Introduction 💅

okay so in wireless environments, and especially cellular systems like GSM/GPRS, we need to maximize how efficiently data moves over the radio interface 🔥 radio spectrum is super expensive and has to be used carefully 💸 cellular systems also have to support a lot of users to be economically feasible, which means there's a real limit on how much bandwidth each user gets 😭

compressing the headers of the network and transport protocols that carry user data is one way to use those scarce radio resources better [ROHC] 🦋 but compressing signaling messages from protocols like SIP/SDP should also be considered, so that radio resource usage improves even more 💖 it also boosts service quality by cutting the user idle time at, e.g., call setup ✨ when IP is used end-to-end, new apps like streaming show up on tiny end-hosts like cellular devices 📱 which adds extra traffic to cellular systems 🌈 signaling messages like RTSP [RTSP] should also be considered for compression, to improve both service availability and quality 🫶

new services with their own signaling protocols make it reasonable to look at a scheme that's generic 🧚 generic here means the scheme can be applied efficiently to arbitrary protocols that have certain characteristics, like the ASCII based protocols SIP and RTSP 💜

1.1. Protocol Characteristics 🎀

these application signaling protocols are examples of ones that are expected to be commonly used in the future 🔮 some of their characteristics are described below 💅

1.1.1 SIP 📞

the Session Initiation Protocol [SIP] is an application layer protocol for establishing, modifying and terminating multimedia sessions or calls 🌸 those sessions include Internet multimedia conferences, Internet telephony and similar apps ✨ SIP can be used over either TCP [TCP] or UDP [UDP] 🦋 it's a text based protocol that uses ISO 10646 in UTF-8 encoding 💖

1.1.2 SDP 🎶

the Session Description Protocol [SDP] is used to advertise multimedia conferences and communicate conference addresses and conference tool specific information 📣 it's also used for general real-time multimedia session description purposes 🌈 SDP gets carried in the message body of SIP and RTSP messages 🫶 it's text based too, using the ISO 10646 character set in UTF-8 encoding 💜

1.1.3 RTSP 🎬

the Real Time Streaming Protocol [RTSP] is an application level protocol for controlling the delivery of data with real-time properties, like audio and video 🍿 RTSP may use UDP or TCP (or other) as a transport protocol 🚀 it's also text based, using the ISO 10646 character set in UTF-8 encoding 🧚

1.1.4 Protocol Similarities 👯‍♀️

these protocols have a lot in common 💕 and those similarities will shape how we solve the problems they cause, especially alongside things like cellular radio access 🙈 the similarities are:

  • Requests and replies 😤 when a sender sends a request, it just sits idle until it gets a response 💀 so it usually takes a bunch of round trip times to wrap up something like a SIP session 🔁
  • They're ASCII based 🔤
  • They're generous in size, because they pack in all the info the session participants need 📦
  • SIP and RTSP share a lot of common header field names, methods and status codes 🤝 their traffic patterns are also similar 👀 the signaling mostly happens during the set up phase 🛠️ for SIP, that means most of the signaling is for setting up a phone call or multimedia session 📞 for RTSP, most of it happens before any application data gets transmitted 🎞️

1.2. Cellular System Radio Characteristics 📡

partly to get high utilization out of cellular systems, and partly because radio media is unreliable, cellular links behave a bit differently from a typical fixed link, like copper or fiber 🧵 the big ones are the lossy behavior of cellular links and their large round trip times 😩

quality in a radio system usually changes from one radio frame to another because of fading in the radio channel 🌦️ thanks to the nature of radio media and interference from other radio users, the average bit error rate (BER) can be 10e-3, with a variation roughly between 10e-2 to 10e-4 📉 to deal with those error characteristics, methods like forward error correction (FEC) and interleaving get used 🧩 without them, the BER of a cellular radio channel would be around 10 % 😱 so yeah, radio links are error prone by nature 💀 the final packet loss rate can be reduced further by applying low level retransmissions (ARQ) over the radio channel, but that trades a lower packet loss rate for a larger delay 🐢 applying methods to decrease BER also increases the system delay 🫠 in some cellular systems, the algorithmic channel round trip delay is in the order of 80 ms 🕰️ other delays come from DSP-processing, node-internal delay and transmission 🖥️ a general value for the RTT is hard to pin down, but it might be as high as 200 ms 😭

for cellular systems, having a sufficient number of users per cell is vital 👑 otherwise the system cost would stop deployment in its tracks 🚫 bandwidth has to be used carefully, so the average user bit rate is usually pretty low compared to the average user bit rate in wired line systems 🐌 this matters the most for mass market services like voice 📱

2. Motivation for Signaling Reduction 🧠

this chapter shows why the problems caused by signaling protocol messages matter, by looking at a typical SIP/SDP Call Setup sequence over a narrow band channel 🔍

2.1 Estimation of Call Setup Delay Using SIP/SDP ⏱️

figure 2.1 shows an example of SIP signaling between two termination points with a wireless link in between, plus the resulting delay under certain system assumptions 📊

the numbers here represent a very narrow band link 🪶 a WCDMA system can hit maximum bit rates of up to 2 Mbits/s in ideal conditions, but that would mean one single user eats all the radio resources in the cell 🍽️ for a mass market service like voice, it's always crucial to cut down the bandwidth requirements for each user 💖

   Client                  Network-Proxy     Size [bytes]   Time [ms]
     |                            |
     |---------- INVITE --------->|               620      517+70=587
     |                            |
     |<-- 183 Session progress ---|               500      417+70=487
     |                            |
     |---------- PRACK ---------->|               250      208+70=278
     |                            |
     |<----- 200 OK (PRACK) ------|               300      250+70=320
     :                            :
     |<...... RSVP and SM .......>|
     :                            :
     |---------- COMET ---------->|               620      517+70=587
     |                            |
     |<----- 200 OK (COMET) ------|               450
     |                            |                +
     |<------ 180 Ringing --------|               230      567+70=637
     |                            |
     |---------- PRACK ---------->|               250      208+70=278
     |                            |
     |<----- 200 OK (PRACK) ------|               300
     |                            |                +
     |<--------- 200 OK ----------|               450      625+70=695
     |                            |
     |----------- ACK ----------->|               230      192+70=262

Figure 2.1. SIP signaling delays assuming a link speed of 9600 bits/sec and a RTT of 140 ms. 📈

the one way delay is calculated with this equation 🧮

   OneWayDelay =
        MessageSize[bits]/LinkSpeed[bits/sec] + RTT[sec]/2       (eq. 1)

these are the values that got used 🫧

RTT/2:                     70 ms
LinkSpeed                  9.6 kbps

the delay formula is based on an approximation of a WCDMA radio access method for speech services 🎤 and yeah, the approximation is pretty crude 😅 for example, delays caused by possible retransmissions due to errors get ignored 🙃 these calculations also assume there's only one cellular link in the path, and they take delays in an eventual intermediate IP-network into account 🌐 even though the approximation is crude, it's still good enough to give representative numbers and make comparisons possible 💅 the message size given in Figure 2.1 is typical for a SIP/SDP call setup sequence 💜

✨ part 1 of 3 is done, more parts coming, stay tuned bestie 🎀

2.1.1. Delay Results 💅

okay so, running equation 1 over each SIP/SDP message in the Figure 2.1 example gives a total delay of 4131 ms from the first SIP/SDP message to the last 😭. The RSVP and Session Management (Radio Bearer setup) steps in Figure 2.1 add roughly 1.5 seconds to that total, again using equation 1 💀. BUT there's also RSVP and SM signaling before the SIP INVITE to set up the radio bearer, and that adds roughly another 1.5 seconds. the delay is literally stacking up 📚

In [TSG] there's a comparison between GERAN call setup using SIP and ordinary GSM call setup. A typical GSM call setup takes about 3.6 seconds, while the SIP version comes in at approximately 7.9 seconds. that's a lot of waiting, bestie 🙃

Another situation that would benefit from less signaling is sending signaling messages over narrow bandwidth links in the middle of a call. For GERAN, this leads to frame stealing, and the speech quality suffers as a result 🎙️💔

So yeah, we need solutions that cut down both the signaling delay and the bandwidth it eats, once you factor in the system bandwidth requirements and the service setup delays 🫶

3. Alternatives for Signaling Reduction ✨

More or less attractive solutions to the problems above can be outlined, and there are a few main contenders 👀

  • Increase the user bit rate 🚀

Bumping the bit rate per user means fewer users per cell. Some systems (like WCDMA) can deliver high bit rates, and even variable ones, e.g., when new sessions are set up. But other systems, like GSM/EDGE, can't hit those high rates in every situation. At cell borders, for example, the signal strength to noise ratio is lower, and that gives you a lower bit rate. In general, an unnecessary increase of the bit rate SHOULD be avoided, because of the higher system cost it brings and the possibility of denial of service. That denial of service could happen, for example, if there isn't enough bandwidth to send the large setup message within the required time period, which is set for QoS reasons 🚫

  • Decrease the RTT of the cellular link ⏱️

Decreasing the RTT would take substantial system changes, so it's not feasible in the short term 😩 Also, the RTT-delay caused by interleaving and FEC will always be there, no matter which system you use. Without it, the BER would be too high for the received data to be useful, or it would trigger retransmissions, giving an average total delay of the same or higher magnitude. no escape, sadly 💀

  • Optimize message sequence for the protocols 🧩

If the request/response pattern could be eased up, then "keeping the pipe full" could be a way forward. So instead of following the message sequence described in Figure 4.2, more than one message would be sent in a row, even before a response comes back. Iconic, but this would entail protocol changes and MAY be difficult at the current date 🥲

  • Protocol stripping ✂️

Removing fields from a message would shrink the messages to some extent. However, this would cause a loss of transparency, which violates the End-to-End principle, so it's not desirable 🙅‍♀️

  • Compression 🗜️

By compressing messages, the impact of the problems above could be decreased. Compared to the other solutions, compression can be made, and MUST be, transparent to the end-user application. So compression seems to be the most attractive way forward, and honestly it's giving main character energy 👑✨

4. Assumptions 🌸

  • Negotiation 🤝

How the usage of compression gets negotiated is out of scope for this compression solution. That job MUST be handled by, e.g., the protocol whose messages are going to be compressed.

  • Reliable transport 🛡️

With reliable transport, it's assumed that the transport recovers from data that is damaged, lost, duplicated, or delivered out of order, e.g., [TCP].

  • Unreliable transport 🎲

With unreliable transport, it's assumed that the transport does NOT have the capabilities of a reliable transport, e.g., [UDP]. (okay, the vibe is "no safety net" 😭)

5. Requirements 🎀

This chapter states requirements for a signaling compression scheme that's going to be developed in the IETF ROHC WG. The list is serious, but I'll be your hype girl through it 📣

The requirements are split into two parts. Section 5.1 sets general requirements about the Internet infrastructure, and Section 5.2 sets requirements on the scheme itself 💖

5.1. General Requirements

1. Transparency: When a message is compressed and then decompressed, the result MUST be bitwise identical to the original message.

Justification: This makes sure the compression scheme won't cause problems for any current or future part of the Internet infrastructure 🧼

Note: See also requirement 9.

2. Header compression coexistence: The compression scheme MUST be able to coexist with header compression, especially the ROHC protocol.

Justification: Signaling compression is used because bandwidth needs conserving. In that case, header compression will likely be needed too 🤝

3a. Compatibility: The compression scheme MUST be constructed in such a way that it allows the above protocols' mechanisms to negotiate whether the compression scheme is applied or not.

Justification: Two entities MUST be able to communicate whether or not the signaling compression scheme is implemented at both of them. bestie, nobody gets left on read 📵

3b. Ubiquity: Modifications to the protocols generating the messages that are to be compressed MUST NOT be required for the compression scheme to work.

Justification: This simplifies deployment of the compression scheme 🚀

Note: This does not preclude making extensions related to the signaling compression scheme to existing protocols, as long as the extensions are backward compatible 🧩

4. Generality: Compression of arbitrary message streams MUST be supported. The signaling compression scheme MUST NOT be limited to certain protocols, traffic patterns or sessions. It MUST NOT assume any message pattern in order to perform compression.

Justification: There might be a future need to compress different ASCII based signaling protocols. This requirement will minimize future work 🙌

Note: This does not preclude optimization for certain streams 💅

5. Unidirectional routes: The compression scheme MUST be able to operate on unidirectional routes, i.e., without explicit feedback messages from the decompressor.

Note: Implementations on unidirectional routes might possibly show degraded performance compared to implementations on bi-directional routes 😬

6. Transport: The solution MUST work for both unreliable and reliable underlying transport protocols, e.g., UDP and TCP.

Justification: The protocols that generate the messages to be compressed MAY use either an unreliable or a reliable underlying transport 🌈

Note: This SHOULD NOT be taken to mean that the same set of solution mechanisms MUST be used over both unreliable and reliable transport. different transports, different vibes 💜

5.2. Performance Requirements

The performance requirements in this section and the following subsections are valid for both unreliable and reliable underlying transport ✨

7. Scalability: The scheme MUST be flexible to accommodate a range of compressors/decompressors with varying memory and processor capabilities.

Justification: A primary target for the signaling compression scheme is cellular systems, where the mobile terminals have varying capabilities 📱

8. Delay: The signaling compression MUST NOT noticeably add to the delay experienced by the end user.

Justification: Cutting the user-experienced delay is the main purpose of signaling compression ⏩

Note: This requirement is intended to prevent schemes that achieve compression efficiency at the expense of delay. In other words, queuing messages to improve compression efficiency SHOULD be avoided 🙅‍♀️

The following requirements are grouped into two subsections: a robustness section and a compression efficiency section 🗂️

5.2.1. Robustness 🛡️

The requirements in this section concern when compressed messages should be correctly decompressed. The transparency requirement (the first requirement) covers faulty decompressed messages 🔍

9. Residual errors: The compression scheme MUST be resilient against errors undetected by lower layers. In other words, the probability of incorrect decompression caused by such undetected errors MUST be low.

Justification: A primary target for the signaling compression scheme is cellular systems, where undetected errors might be introduced on the cellular link 📡

10. Error propagation: Propagation of errors due to signaling compression SHOULD be kept at an absolute minimum. Loss or damage to a single or several messages between compressor and decompressor SHOULD NOT prevent compression and decompression of later messages.

Justification: Error propagation reduces resource utilization and quality 📉

11. Delay: The compression scheme MUST be able to perform compression and decompression of messages under all expected delay conditions ⏰

5.2.2. Compression Efficiency 📊

This section states requirements related to compression efficiency 🧠

12. Message loss: Loss or damage to a single or several messages on the link between compressor and decompressor SHOULD NOT prevent the usage of later messages in the compression and decompression process.

13. Moderate message misordering: The scheme SHOULD allow for the correct decompression of messages that have been moderately misordered (1-2 messages) between compressor and decompressor. The scheme SHOULD NOT prevent the usage of later messages in the compression and decompression process.

Justification: Misordering is frequent on the Internet, and this kind of misordering is common 🌀

6. Security Considerations 🔐

Security is serious business, bestie. Read this part carefully 🚨

A protocol specified to meet these requirements MUST be able to cope with packets that have undergone security measures, such as encryption, without adding any security risks. This document, by itself, however, does not add any security risks 🔒

7. IANA Considerations 📋

A protocol which meets these requirements MAY require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement 🫶

8. References 📚

Okay bestie, here are the receipts! 🧾💅 Every source we've been leaning on is listed below, with all the details.

  • [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 🦋
  • [RTSP] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. 🎀
  • [SDP] Handley, H. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🌸
  • [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 💜
  • [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 🧚
  • [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. ⭐
  • [TSG] Nortel Networks, "A Comparison Between GERAN Packet-Switched Call Setup Using SIP and GSM Circuit-Switched Call Setup Using RIL3-CC, RIL3-MM, RIL3-RR, and DTAP", 3GPP TSG GERAN #2, GP-000508, 6-10 November 2000. 🍓

9. Author's Address 🫶

Meet the brain behind it all, Hans Hannu from Ericsson in Lulea, Sweden! 🇸🇪✨

Hans Hannu
Box 920
Ericsson AB
SE-971 28 Lulea, Sweden

Phone:  +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se

Time for the legal bit, and yes, it matters, so read it all. 🙈

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🧡

Shoutout to the people keeping the RFC Editor function running! 👑

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from