A Negative Acknowledgement Mechanism for Signalling Compression

Versions: 00 01                                                         
Network Working Group                                        A. B. Roach
Internet-Draft                                               dynamicsoft
Expires: April 1, 2003                                   October 1, 2002

    A Negative Acknowledgement Mechanism for Signalling 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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 1, 2003.

Copyright Notice

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


   This document describes a mechanism that allows Signalling
   Compression (SigComp) implementations to report precise error
   information upon receipt of a message which cannot be decompressed.
   This negative feedback can be used by the recipient to make fine-
   grained adjustments to the compressed message before retransmitting
   it, allowing for rapid and efficient recovery from error situations.

Roach                    Expires April 1, 2003                  [Page 1]

Internet-Draft                SigComp NACK                  October 2002

1. Introduction

   Signalling Compression (see reference [1]), often called "SigComp",
   defines a protocol for transportation of compressed messages between
   two nodes.  One of the key features of SigComp is the ability of the
   sending node to request that the receiving node store state objects
   for later retrieval.

1.1 The Problem

   While the "SigComp - Extended Operations" document (reference [2])
   defines a mechanism that allows for confirmation of state creation,
   operational experience with the SigComp protocol has demonstrated
   that there are still several circumstances in which a sender's view
   of the shared state differs from the reciever's view.  A non-
   exhaustive list of the circumstances in which such failures may occur
   are detailed below.

1.1.1 Compartment Disposal

   In SigComp, stored states are associated with compartments.
   Conceptually, the compartments represent one instance of a remote
   application.  These compartments are used to limit the amount of
   state that each remote application is allowed to store.  Compartments
   are created upon receipt of a valid SigComp message from a remote
   application.  In the current protocol, applcations are expected to
   signal when they are finished with a compartment so that it can be
   deleted (by using the S-bit in requested feedback data).

   Unfortunately, expecting the applications to be well-behaved is not
   suffcient to prevent state from piling up.  Unexpected client
   failures, reboots, and loss of connectivity can cause compartments to
   become "stuck" and never removed.  To prevent this situation, it
   becomes necessary to implement a scheme by which compartments that
   appear disused may eventually be discarded.

   While the preceding facts make such a practice necessary, discarding
   compartments without explicit signalling can have the unfortunate
   side effect that active compartments are sometimes discarded.  This
   leads to a different view of state between the server and the client.

1.1.2 Client Restart

   The prime motivation behind SigComp was compression of messages to be
   sent over a radio interface.  Consequently, almost all deployments of
   SigComp will involve a mobile unit as one of the the endpoints.  Such
   units are not generally highly available.  Node restarts (due to e.g.
   a battery running out) will induce situations in which the network-

Roach                    Expires April 1, 2003                  [Page 2]

Internet-Draft                SigComp NACK                  October 2002

   based server beleives that the client contains several states that
   are no longer actually available.

1.1.3 Server Failover

   Many high-availability schemes for IP servers involve load
   distribution through a set of redundant servers that appear to the
   sending user to be routers to the same destination IP address.  In
   these systems, the traffic to a failed server is routed to an
   equivalently provisioned server.

   Although SigComp state can be replicated amongst such a cluster of
   servers, maintaining integrity of such states requires a two-phase
   commit process, which adds a great deal of complexity to the server,
   and can degrade performance significantly.

1.2 The Solution

   Although SigComp allows returned SigComp parameters to signal that
   all states have been lost (by setting "state_memory_size" to 0 for
   one message in the reverse direction), such an approach provides an
   incomplete solution to the problem.  In addition to wiping out an
   entire compartment when only one state is corrupt or missing, this
   approach suffers from the unfortunate behavior that it requires a
   compressed application-level message in the reverse direction before
   recovery can occur.  In many cases, such as SIP-based mobile
   terminals, such messages may be seldom; in others (pure client/server
   deployments), they won't ever happen.

   The proposed solution to this problem is a simple Negative
   Acknowledgement (NACK) mechanism which allows the recipient to
   communicate to the sender that a failure has occured.  This NACK
   contains a reason code that communicates the nature of the failure.
   For certain types of failures, the NACK will also contain additional
   details that might be useful in recovering from the failure.

Roach                    Expires April 1, 2003                  [Page 3]

Internet-Draft                SigComp NACK                  October 2002

2. Node Behavior

   The following sections detail the behavior of nodes sending and
   receiving SigComp NACKs.  The actual format and values are described
   in section Section 3.

2.1 Normal SigComp Message Transmission

   Although normal in all other respects, SigComp implementations that
   use the NACK mechanism need to calculate and store a SHA-1 hash for
   each SigComp message that they send.  This must be stored in such a
   way that, given the SHA-1 hash, the implementation is able to locate
   the compartment with which the sent message was associated.  Further,
   when a reliable transport is being used, the implementation must be
   able to retrieve the plain-text version of the original message.

2.2 Receiving a "Bad" SigComp Message

   When a received SigComp message causes a decompression failure, the
   recipient forms and sends a SigComp NACK message.  This NACK message
   contains a SHA-1 hash of the received SigComp message that could not
   be decompressed.  It also contains the exact reason decompression
   failed, as well as any additional details that might assist the NACK
   recipient to correct any problems.  See section Section 3 for more
   information about formatting the NACK message and its fields.

   For a connection-oriented transport, such as TCP, the NACK message is
   sent back to the originator of the failed message over that same

   For a stream-based transport, such as TCP, the standard SigComp
   delimiter of 0xFFFF is used to terminate the NACK message.

   For a connectionless transport, such as UDP, the NACK message is sent
   back to the originator of the failed message at the port and IP
   address from which the message was sent.  Note that this may or may
   not be the same port to which the appliation would typically receive

2.3 Receiving a SigComp NACK

   The first action taken upon receipt of a NACK is an attempt to find
   the message to which the NACK corresponds.  This search is performed
   using the 20-byte SHA-1 hash contained in the NACK.  Once the
   matching message is located, further operations are performed based
   on the compartment that was associated with the sent message.

   Further behavior of a node upon receiving a SigComp NACK depends on

Roach                    Expires April 1, 2003                  [Page 4]

Internet-Draft                SigComp NACK                  October 2002

   whether a reliable or unreliable transport is being used.

2.3.1 Unreliable Transport

   When SigComp is used over an unreliable transport, the application
   has no reasonable expectation that the transport layer will deliver
   any particular message.  It then becomes the application layer's
   responsibility to ensure that data is retransmitted as necessary.  In
   these circumstances, the NACK mechanism relies on such behavior to
   ensure delivery of the message, and never performs retransmissions on
   the application's behalf.

   When a NACK is received for a message sent over an unreliable
   transport, the NACK recipient uses the contained information to make
   appropriate adjustments to the compressor associated with the proper
   compartment.  The exact nature of these adjustments are specific to
   the compression scheme being used, and will vary from implementation
   to implementation.  The only requirement on these adjustments is that
   they must have the effect of compensating for the error that has been
   indicated (e.g.  by removing the state that the remote node indicates
   it cannot retreive).

   In particular, when an unreliable transport is used, the original
   message must not be retransmitted by the SigComp layer upon receipt
   of a NACK.  Instead, the next application initiated transmission of a
   message will take advantage of the adjustments made as a result of
   processing the NACK.

2.3.2 Reliable Transport

   When a reliable transport is employed, the application makes a basic
   assumption that any message passed down the stack will be
   retransmitted as necessary to ensure that the remote node receives
   it.  As such, many such application provide no application-level
   reliability mechanism.  Because SigComp acts as a shim between the
   transport-layer and the application, it becomes the responsibility of
   the SigComp implementation to ensure such retransmission in the case
   of a detected failure.

   When a NACK is received for a message sent over a reliable transport,
   the NACK recipient uses the contained information to make appropriate
   adjustments to the compressor associated with the proper compartment.
   The exact nature of these adjustments are specific to the compression
   scheme being used, and will vary from implementation to
   implementation.  The only requirement on these adjustments is that
   they must have the effect of compensating for the error that has been
   indicated (e.g.  by removing the state that the remote node indicates
   it cannot retreive).

Roach                    Expires April 1, 2003                  [Page 5]

Internet-Draft                SigComp NACK                  October 2002

   After such adjustments are made, the SigComp layer re-compresses the
   original message and re-sends it to the original recipient.

Roach                    Expires April 1, 2003                  [Page 6]

Internet-Draft                SigComp NACK                  October 2002

3. Message Format

   SigComp NACK packets are syntactically valid SigComp messages which
   have been specifically designed to be safely ignored by
   implementations that do not support the NACK mechanism.

   In particular, NACK messages are formatted as the second variant of a
   SigComp message (typically used for code upload) with a "code_len"
   field of zero and no input data.  The NACK-specific information
   (message identifier, reason for failure, and error details) appears
   in the "returned feedback item" field.  Further, the "destination"
   field is used as a version identifier to indicate which version of
   NACK is being employed.

3.1 Message Fields

   Although the format of NACK messages are the same as the second
   variant of normal SigComp messages, it is useful to demonstrate the
   specific fields as they appear inside the "returned feedback item"

Roach                    Expires April 1, 2003                  [Page 7]

Internet-Draft                SigComp NACK                  October 2002


             0   1   2   3   4   5   6   7
           | 1   1   1   1   1 |T=1|   0   | 0
           | 1 |       NACK Length         | 1
           |          Reason Code          | 2
           |                               | 3
           : SHA-1 Hash of failed message  :
           |                               | 22
           |                               | 23
           :         Error Details         :
           |                               |
           |         code_len = 0          | detail_length + 23
           | code_len = 0  |  version = 1  | detail_length + 24

                 Figure 1: SigComp NACK Message Format


   o  "Reason Code" is a one-byte value that indicates the nature of the
      decompression failure.  The specific codes are given in section
      Section 3.2

   o  "SHA-1 Hash of failed message" contains the full 20-byte SHA-1
      hash of the SigComp message that could not be decompressed.  This
      information allows the NACK recipient to locate the message that
      failed to decompress so that adjustments to the correct
      compartment can be performed.  When performing this hash, the
      entire SigComp message is used, from the header byte (binary
      11111xxx) to the end of the input.  Any lower-level protocol
      headers (such as UDP or IP) and message delimiters (the 0xFFFF
      that marks message boundaries in stream protocols) are not
      included in the hash.  When used over a stream based protocol, any
      0xFFxx escape sequences are un-escaped before performing the hash

   o  "Error Details" provides any additional information that might be
      useful in correcting the problem that caused decompression
      failure.  Its meaning is specific to the "Reason Code".  See

Roach                    Expires April 1, 2003                  [Page 8]

Internet-Draft                SigComp NACK                  October 2002

      section Section 3.2 for specific information on what appears in
      this field.

   o  "Code_len" is the "code_len" field from a standard SigComp
      message.  It is always set to "0" for NACK messages.

   o  "Version" gives the version of the NACK mechanism being employed.
      This document defines version 1.

3.2 Reason Codes

   Note that many of the status codes are more useful in debugging
   interoperability problems than with on-the-fly correction of errors.
   The "STATE_NOT_FOUND" error is a notable exception: it will generally
   cause the NACK receipient to encode future messages so as to not use
   the indicated state.

   Upon receiving the other status messages, an implementation would
   typically be expected to either use a different set of bytecodes or,
   if that is not an option, to send that specific message uncompressed.

Roach                    Expires April 1, 2003                  [Page 9]

Internet-Draft                SigComp NACK                  October 2002


       Error                      Code Details
       -------------------------- ---- ---------------------------
       STATE_NOT_FOUND              1  State ID (6 - 20 bytes)
       CYCLES_EXHAUSTED             2  Cycles Per Bit (1 byte)
       USER_REQUESTED               3
       SEGFAULT                     4
       OUTPUT_OVERFLOW              8
       STACK_UNDERFLOW              9
       BAD_BITORDER                10
       DIV_BY_ZERO                 11
       SWITCH_VALUE_TOO_HIGH       12
       HUFFMAN_NO_MATCH            15
       MESSAGE_TOO_SHORT           16
       BYTECODES_TOO_LARGE         18  Memory size (2 bytes)
       INVALID_OPCODE              19

   Only the three errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", and
   "BYTECODES_TOO_LARGE" contain details; for all other error codes, the
   "Error Details" field has zero length.

                  Figure 2: SigComp NACK Reason Codes


        A state that was referenced (either using STATE-ACCESS
        instruction or in the actual SigComp message itself) cannot be
        found.  The "details" field contains the state identifier for
        the state that could not be found.

        Decompression of the message has taken more cycles than were
        allocated to it.  The "details" field contains a one-byte value
        that communicates the number of cycles per bit.  The cycles per
        bit is represented as an unsigned 8-bit integer (i.e.  not

        The DECOMPRESSON-FAILURE opcode has been executed.

Roach                    Expires April 1, 2003                 [Page 10]

Internet-Draft                SigComp NACK                  October 2002

   4.   SEGFAULT
        An attempt to read from or write to memory that is outside of
        the UDVM's memory space has been attempted.

        More than four requests to store or delete state objects have
        been requested.

        A state id length less than 6 or greater than 20 has been

        A state priority of 65535 has been specified when attempting to
        store a state.

        The decompressed message is too large to be decoded by the
        receiving node.

        An attempt to pop a value off the UDVM stack was made with a
        stack_fill value of 0.

        An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with
        the "input_bit_order" register set to an invalid value (i.e.
        one of the upper five bits is set).

   11.  DIV_BY_ZERO
        A DIVIDE or REMAINDER opcode was encountered with a divisor of

        The input to a SWITCH opcode exceeds the number of branches

        An INPUT instruction was encountered that attempted to input
        more than 16 bits.

        The first "number of bits" parameter to a INPUT-HUFFMAN opcode
        is zero.

        The input string does not match any of the bitcodes in the
        INPUT-HUFFMAN opcode.

Roach                    Expires April 1, 2003                 [Page 11]

Internet-Draft                SigComp NACK                  October 2002

        When attempting to decode a SigComp message, the recipient
        determined that there were not enough bytes in the message for
        it to be valid.

        The "code location" field in the SigComp message was set to the
        invalid value of 0.

        The bytecodes that a SigComp message attempted to upload exceed
        the amount of memory available in the receiving UDVM.  The
        details field is a two-byte expression of the
        DECOMPRESSION_MEMORY_SIZE of the receiving UDVM.  This value is
        communicated most-significant-byte first.

        The UDVM attempted to identify an undefined byte value as an

Roach                    Expires April 1, 2003                 [Page 12]

Internet-Draft                SigComp NACK                  October 2002

4. Security Considerations

4.1 Reflector Attacks

   Because SigComp NACK messages trigger responses, it is possible to
   trigger them by intentionally sending malformed messages to a SigComp
   implementation with a spoofed IP address.  However, because such
   actions can only generate one message for each message sent, they
   don't serve as amplifier attacks.  Futher, due to the reasonably
   small size of NACK packets, there cannot be a significant increase in
   the size of the packet generated.

   It is worth noting that nearly all deployed protocols exhibit this
   same behavior.

4.2 NACK Spoofing

   Although it is possible to forge NACK message as if they were
   generated by a different node, the damage that can be caused is
   minimal.  Reporting a loss of state will typically result in nothing
   more than the re-transmission of that state in a subsequent message.
   Other failure codes would result in the next message being sent using
   an alternate compression mechanism, or possibly uncompressed.

   Although all of the above consequences result in slightly larger
   messages, none of them have particularly catastrophic implications
   for security.

Roach                    Expires April 1, 2003                 [Page 13]

Internet-Draft                SigComp NACK                  October 2002


   [1]  Price, R., "Signaling Compression", draft-ietf-rohc-sigcomp-07
        (work in progress), June 2002.

   [2]  Hannu, H., "SigComp - Extended Operations", draft-ietf-rohc-
        sigcomp-extended-04 (work in progress), June 2002.

Author's Address

   Adam Roach
   5100 Tennyson Pkwy
   Suite 1200
   Plano, TX  75024

   EMail: adam@dynamicsoft.com

Roach                    Expires April 1, 2003                 [Page 14]

Internet-Draft                SigComp NACK                  October 2002

Appendix A. Comments and Feedback

   Editorial comments should be directed to the author at
   adam@dynamicsoft.com.  Discussion of the mechanism described in this
   document should be directed to the ROHC mailing list (rohc@ietf.org).

Roach                    Expires April 1, 2003                 [Page 15]

Internet-Draft                SigComp NACK                  October 2002

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

   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


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

Roach                    Expires April 1, 2003                 [Page 16]