Network Working Group Zhigang Liu INTERNET-DRAFT Nokia Expires: April 2003 October 14, 2002 A Recovery Mechanism for Signaling Compression Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a submission to the IETF ROHC WG. Comments should be directed to its mailing list, rohc@ietf.org. Abstract This document defines a recovery mechanism for signaling compression (SigComp). It allows a decompressor to signal to its peer compressor in case it has lost synchronization with the compressor. The compressor can thereafter take appropriate actions. The signal can be carried using state announcement mechanism or reserved bits in the requested feedback data as defined in SigComp. Liu [Page 1] INTERNET-DRAFT SigComp Recovery October 14, 2002 1. Introduction [SIGCOMP] defines a solution for compressing messages generated by application protocols such as SIP [RFC-2543] and RTSP [RFC-2326]. To guarantee successful decompression, the compressor and decompressor must maintain synchronization on states. [SIGCOMP-EXT] describes a few mechanisms (e.g. acknowledgments, checkpoint state) that can be used for this purpose. However, there are still certain scenarios that cannot be handled by current SigComp specification. For example, if a decompressor loses some or all of its states due to a sudden shortage of memory, memory corruption or even crash, there is no standardized mechanism in SigComp that allows the decompressor to inform the loss of synchronization to its peer compressor. This document introduces a solution to address the problem. 2. Discussions in the Past The issue has been discussed during the development of SigComp. A few solutions were proposed which did not require work within SigComp. 1) Sender timeout and retransmission. Usually, a signaling protocol has the request-response message sequence. If the sender has not received response to a compressed message sent earlier after timeout period, it can assume the compressed message was lost or corrupted and retransmit the compressed message. It repeats this for N timeout periods. After that, it will assume the reason of not receiving response is decompression failure due to loss of synchronization. It can then start resynchronization procedure (e.g. re-upload states). Before the procedure is finished, it can either compresses subsequent messages by using only static dictionary [SIP-DICT], or it can send subsequent messages uncompressed. One fundamental problem with above solution is that there are many possible reasons for the sender not to receive the expected response: a) the compressed message sent by the sender is lost; b) the compressed message is corrupted and thus causes decompression failure; c) decompressor loses synchronization and therefore cannot decompress; and d) the response message is lost. The sender simply cannot tell which case it is dealing with. In the case when a loss of synchronization indeed happened, the sender still blindly performs N retransmissions of compressed messages which are deemed to be discarded by the receiver. This leads to unnecessary delay. Note that setting N to 1 does not solve the problem either as that means all the other cases will be incorrectly treated as loss of synchronization. The consequence is Liu [Page 2] INTERNET-DRAFT SigComp Recovery October 14, 2002 lower compression ratio and higher transmission latency. 2) Signal the loss of synchronization outside of SigComp, e.g. at application layer. This simplifies SigComp. However, it means extra standardization work at application layer. In particular, it may require modifications to existing specifications of application layer. Since the synchronization problem is introduced at SigComp layer, it would be good to have the problem resolved within SigComp. This will ease the deployment of SigComp in various application environments. 3. Solutions Within SigComp Essentially, all we need is an in-band (i.e. within SigComp layer) signaling mechanism that allows decompressor to inform its peer compressor when a loss of synchronization has happened. There are two options to carry a signal. Both will be presented below. The first one is the best in our view. However, the second one also has its merit as a quick solution. 3.1. Send Signals Using State Announcement [SIGCOMP] defines a state announcement mechanism that allows a SigComp endpoint to announce its locally available states to any remote endpoints. Basically, the announcing endpoint can encode a list of partial state identifiers for those locally available states as part of the returned SigComp parameters ([SIGCOMP], section 9.4.9). A state identifier is the (SHA-1) cryptographic hash calculated over the state. When a remote endpoint receives such an announcement, it can use those locally available states to compress messages sent to the announcing endpoint. This makes it possible to improve compression efficiency without the need of actually uploading those states, assuming that the content of those states are known by the receiving endpoint out of band, e.g. pre-defined in a published document. We can use the above mechanism to send signals as follows. - For each signal, define a locally available state that maps to it. Details will be given below. - To send a signal, a SigComp endpoint simply announces the corresponding state following the state announcement procedure. Liu [Page 3] INTERNET-DRAFT SigComp Recovery October 14, 2002 - When receiving a state announcement, the receiving SigComp endpoint will check the (partial) state identifier received against those of known states that are defined for signaling purpose. If a match is found, the endpoint will translate the state announcement back to the signal semantics it carries. The definition of a state for signaling purpose can be quite arbitrary. However, one key requirement is that it must be globally unique and cannot be easily generated by accident. This is to guarantee the interoperability with those SigComp endpoints that are unaware of this document. Namely, they simply discard the received state announcement since they cannot find the corresponding state. The uniqueness of a state can be achieved by adding a "random salt" to the state value. In general, the length of a random salt should be at least 20 bytes (the length of a state identifier). Note: a SigComp endpoint does not need to store the states themselves defined for signaling purpose. That is because only state identifier is of significance to derive the corresponding signal. The advantages of this approach: - It does not require any changes to current SigComp specification. - There are no interoperability issues (see above). Of course, if a SigComp endpoint is not aware of a particular state, the signals embedded in the state announcement will be discarded. - The signal can be either piggybacked on a compressed application message or sent in a standalone SigComp message (i.e. without application message). The former is required under the generic security model of [SIGCOMP]. The latter is allowed if the receiving endpoint has means to authenticate the standalone message, e.g. when SigComp runs over IPsec as in the case of 3GPP. - Extensibility. New signals can be easily added by defining new states. Disadvantages: - Slight overhead at SigComp endpoints. An endpoint needs to store 20 bytes state identifier for each signal. - Overhead on the wire. This depends on how state announcement is implemented. A simple implementation that sends the (partial) state identifiers explicitly in a SigComp message will cost 6 - Liu [Page 4] INTERNET-DRAFT SigComp Recovery October 14, 2002 20 bytes per signal. However, a smarter implementation may upload a byte code that can parse some bit flags in a SigComp message and generate the state announcement locally according to the big flags. In that case, the overhead on the wire is 1 bit per signal plus the one time cost of uploading the byte code. Either way, the signals are only sent for abnormal situations that should not occur frequently. Therefore, the overhead on the wire is not a big concern. 3.2. Send Signals Using Reserved Bits Another option to carry signals is to use the reserved bits in requested feedback data ([SIGCOMP], Figure 12. copied below). 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | reserved | Q | S | I | requested_feedback_location +---+---+---+---+---+---+---+---+ | | : requested feedback item : if Q = 1 | | +---+---+---+---+---+---+---+---+ Figure 12: Format of requested feedback data The advantage of this approach is simplicity. The drawbacks are: - It does not work with current SigComp Version (0x01); - Each signal consumes one reserved bit and there are only five of them. Therefore, there is not much room for extensibility. 3.3. Proposed Recovery Mechanism To address the loss of synchronization problem, we propose to standardize a RESET signal. The RESET signal can be carried in either of the two options as described previously. For the state announcement option, we define the following state for RESET signal. Basically, the state_value is a 14-byte text string "SigComp-RESET-" followed a random salt of 42 bytes long. The state_length is chosen such that the total size of the state (for the purpose of state identifier calculation) is 64 bytes - the block size of SHA-1 [PUB-180-1]. This avoids the padding. Liu [Page 5] INTERNET-DRAFT SigComp Recovery October 14, 2002 Name: Value: ===================== ======================== state_identifier 0xE140A4AB1AD80E52F731619E5CA63AA451163675 state_length 0x0038 state_address 0x0000 (not relevant for the dictionary) state_instruction 0x0000 (not relevant for the dictionary) minimum_access_length 0x0006 state_value see below 0000 5369 6743 6F6D 702D 5245 5345 542D 88C3 SigComp-RESET-.. 0010 B6D1 A3AB 09A0 373C 4BBA 30DC 729C 91E9 ......7 (work in progress), Internet Engineering Task Force, June 2002. [SIGCOMP-EXT] Hannu, et al., "SigComp - Extended Operations", (work in progress), Internet Engineering Task Force, June 2002. [RFC-2543] Handley, et al., "SIP: Session Initiation Protocol", RFC 2543, Internet Engineering Task Force, March 1999 [RFC-2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, Internet Engineering Task Force, April 1998. [SIP-DICT] Garcia, et al., "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) static dictionary for Signaling Compression (SigComp)", (work in progress), Internet Engineering Task Force, August 2002. [PUB-180-1] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. Liu [Page 7] INTERNET-DRAFT SigComp Recovery October 14, 2002 8. Authors' Addresses Zhigang Liu Nokia Research Center Phone: +1 972 894-5935 6000 Connection Drive Fax: +1 972 894-4589 Irving, TX 75039 E-mail: zhigang.c.liu@nokia.com USA 9. Full copyright statement Copyright (C) The Internet Society (2002). 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. This Internet-Draft expires April 14, 2003. Liu [Page 8]