[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-rohc-tcp-taroc) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 4996

Network Working Group         Qian Zhang, (ed.), Microsoft Research Asia
Internet Draft                               Lars-Erik Jonsson, Ericsson
Expires: January 2003              HongBin Liao, Microsoft Research Asia
                                         Mark A West, Siemens/Roke Manor

                                                              July, 2002


              TCP/IP Header Compression for ROHC (ROHC-TCP)
                        <draft-ietf-rohc-tcp-02.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [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 obsolete 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.

Abstract

   Existing TCP/IP header compression schemes do not work well on noisy
   links, especially the one with high bit error rate and long
   roundtrip time. For many bandwidth limited links where header
   compression is essential, such characteristics are common. In
   addition, existing schemes [VJHC, IPHC] have not addressed how to
   compress TCP options such as SACK [RFC2018, RFC2883] and Timestamps
   [RFC1323].

   A robust and efficient header compression scheme for TCP/IP, called
   ROHC-TCP, is proposed within the basic RObust Header Compression
   [RFC3095] framework.

Zhang, et al.                                                 [Page 1]

                       draft-ietf-rohc-tcp-02.txt


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1. Introduction....................................................5
   2. Terminology.....................................................5
   3. Background......................................................7
      3.1 Existing TCP/IP header compression schemes..................7
      3.2 Classification of header fields.............................8
      3.3 Characteristics of the short-lived TCP transfers............9
      3.4 Classification of replicable header fields.................10
   4. TCP/IP header compression framework............................12
      4.1 Compression and decompression states.......................12
         4.1.1 Compressor states.....................................12
            4.1.1.1. Initialization and Refresh (IR) state...........12
            4.1.1.2. First Order (FO) State..........................13
            4.1.1.3. Second Order (SO) State.........................13
         4.1.2. Decompressor states..................................13
      4.2 Modes of operation.........................................13
         4.2.1. Unidirectional mode -- U-mode........................14
         4.2.2. Bi-directional mode -- B-mode........................14
      4.3. Impairment considerations.................................14
   5. The Protocol...................................................15
      5.1. Data structures...........................................15
      5.2. ROHC-TCP packet formats from compressor to decompressor...15
      5.3. Parameters needed for mode transition in ROHC-TCP.........16
      5.4 Robustness and efficiency maintenance......................16
      5.5 Operation in U-mode........................................17
         5.5.1. Compressor state and logic...........................17
            5.5.1.1. State transition logic (U-mode).................18
         5.5.2. Decompressor logic...................................21
            5.5.2.1. No Context State................................21
            5.5.2.2. Full Context State..............................21
      5.6. Operations in B-mode......................................22
         5.6.1. Compressor states and logic..........................22
            5.6.1.1. Master Sequence Number (MSN) for packet
            acknowledging............................................22
            5.6.1.2. State transition logic..........................23
            5.6.1.3. Compression logic and packets used..............23
         5.6.2. Decompressor states and logic........................23
      5.7. Mode transitions..........................................24
         5.7.1. Compression and decompression during mode transitions24
         5.7.2. Transition from Unidirectional to Bidirectional mode.25
         5.7.3. Transition to Unidirectional mode....................25
      5.8. Context Replication.......................................26
      5.9. Implementation optimizations..............................26
         5.9.1. Determine the value N................................26
         5.9.2. Determine the frequency of updating context..........26
         5.9.3. Tracking-based TCP congestion window estimation......27
            5.9.3.1. General principle of congestion window tracking.27
            5.9.3.2. Tracking based on Sequence Number...............27
            5.9.3.3. Tracking based on Acknowledgment Number.........29
            5.9.3.4. Further discussion on congestion window tracking30

Zhang (ed.), et al.                                           [Page 2]

                       draft-ietf-rohc-tcp-02.txt


            5.9.3.5. Determine the value K in congestion window
            estimation...............................................31
         5.9.4. Possible optimization in U-mode......................31
   6. Coding Scheme and compressed packet header format..............32
      6.1. Fixed-payload encoding....................................33
      6.2. ROHC Profile for compression of TCP/IP....................33
   7. Security considerations........................................46
   8. Acknowledgements...............................................46
   9. References.....................................................46
   10. Authors' addresses............................................49
   Appendix A - Detailed classification of header fields.............50
      A.1. General classification....................................50
         A.1.1. IP header fields.....................................51
            A.1.1.1. IPv6 header fields..............................51
            A.1.1.2. IPv4 header fields..............................52
         A.1.2. TCP header fields....................................55
         A.1.3. Summary for IP/TCP...................................55
      A.2. Analysis of change patterns of header fields..............56
         A.2.1. IP header............................................58
            A.2.1.1. IP Traffic-Class / Type-Of-Service (TOS)........58
            A.2.1.2. ECN Flags.......................................59
            A.2.1.3. IP Identification...............................59
            A.2.1.4. Don't Fragment (DF) flag........................61
            A.2.1.5. IP Hop-Limit / Time-To-Live (TTL)...............61
         A.2.2. TCP header...........................................61
            A.2.2.1. Sequence number.................................62
            A.2.2.2. Acknowledgement number..........................63
            A.2.2.3. Reserved........................................63
            A.2.2.4. Flags...........................................63
            A.2.2.5. Checksum........................................64
            A.2.2.6. Window..........................................65
            A.2.2.7. Urgent pointer..................................65
         A.2.3. Options..............................................65
            A.2.3.1. Options overview................................65
            A.2.3.2. Option field behavior...........................66
      A.3. Some observations.........................................71
         A.3.1. Implicit acknowledgements............................71
         A.3.2. Field dependence and packet behavior.................71
         A.3.3. Correlation and size constraint for TCP options......71
         A.3.4. Short-lived flows....................................72
         A.3.5. Shared path..........................................75


Zhang (ed.), et al.                                           [Page 3]

                       draft-ietf-rohc-tcp-02.txt



   Document History

   00  January 31, 2002  First release.
   01  March 16, 2002    Revise structure of the draft;
                          Refine operation mode and mode transition of
                          the state machine;
                          Add solution for context replication;
                          Add profile for context replication;
                          Refine the TCP/IP behavior analysis.
   02  July 1, 2002      Refine the issues related to context
                          replication, MSN, and mode transition
                          according to the discussions on mailing list;
                          Refine some statements about previous work.

























Zhang (ed.), et al.                                           [Page 4]

                       draft-ietf-rohc-tcp-02.txt


1. Introduction

   The necessity and importance of doing TCP/IP header compression on
   low- or medium-speed links have been discussed in [IPHC].

   However, some links, such as cellular links, have characteristics
   that make header compression as defined in [IPHC, VJHC] perform less
   than well. The most important characteristic is the lossy behavior
   of cellular links, where a bit error rate (BER) as high as 1e-3 must
   be accepted to keep the radio resources efficiently utilized. In
   severe operating situations, the BER can be as high as 1e-2.
   Although TCP traffic has usually tended to be sent over reliable
   links, there are still many scenarios where TCP header compression
   will be implemented over less reliable links [RFC-3150, PILC-ARQ],
   making robustness an important objective also for the new TCP
   compression scheme. The other problematic characteristic is the long
   round-trip time (RTT) of the cellular link, which is due to FEC
   combined with interleaving, processing delay and delays from the
   transport in the radio network. A typical RTT varies between a few
   hundred milliseconds to one second. The link layer ARQ will make
   this RTT even larger.

   Current TCP header compression schemes are limited in their handling
   of the TCP options field.  For [IPHC], any change in the options
   field (caused by timestamps or SACK, for example) renders the entire
   field uncompressible (leaving the TCP/IP header itself compressible,
   however).  Even worse, for [VJHC] such a change in the options field
   effectively disables TCP/IP header compression altogether.

   Other shortcomings of existing TCP/IP header compression schemes
   ([IPHC, VJHC]) are that headers of handshaking packets (SYNs and
   FINs) are not compressed. Especially, if many short-lived TCP
   connections run across the link, the compression of TCP handshaking
   packets may greatly improve the overall header compression ratio.

   Thus a viable header compression scheme for cellular links must be
   able to handle loss on the link between the compression and
   decompression point as well as loss before the compression point.
   Meanwhile, the new header compression scheme needs to consider how
   to efficiently compress the short-lived TCP transfers and the TCP
   options, such as SACK and Timestamp.

   Bandwidth is the most costly resource in cellular links. Processing
   power is very cheap in comparison. Implementation or computational
   simplicity of a header compression scheme is therefore of less
   importance than its compression ratio and robustness.

   This document describes a new header compression scheme for TCP/IP
   header compression (ROHC-TCP), which is robust against packet loss
   and hence achieves good performance over lossy links.

2. Terminology

Zhang (ed.), et al.                                           [Page 5]

                       draft-ietf-rohc-tcp-02.txt



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Compressed header format

     A compressed header format describes how to compress each field in
     the chosen protocol stack. It consists of two parts: a bit pattern
     to indicate to the decompressor which format is being used,
     followed by a list of the compressed versions of each field.

   Context

     The context of the compressor is the state it uses to compress a
     header. The context of the decompressor is the state it uses to
     decompress a header. Either of these or the two in combination are
     usually referred to as "context", when it is clear which is
     intended. The context contains relevant information from previous
     headers in the packet stream, such as static fields and possible
     reference values for compression and decompression. Moreover,
     additional information describing the packet stream is also part
     of the context, for example information about how the IP
     Identifier field changes and the initial window size.

   Context identifiers

     On some channels, the ability to transport multiple packet streams
     is required. It can also be feasible to have channels dedicated to
     individual packet streams. Therefore, ROHC uses a distinct context
     identifier space per channel and can eliminate context identifiers
     completely for one of the streams when few streams share a channel.

   Context replication

     Initialize a new context from an existing one and overwrite some
     of the values to create the new context.

   Loss propagation

     Loss of headers, due to errors in (i.e., loss of or damage to)
     previous header(s) or feedback.

   Profile

     A ROHC profile is a description of how to compress a certain
     protocol stack over a certain type of link. Each profile includes
     one or more sets of compressed header formats and a state machine
     to control the compressor and the decompressor.

   Robustness


Zhang (ed.), et al.                                           [Page 6]

                       draft-ietf-rohc-tcp-02.txt


     The performance of a header compression scheme can be described
     with three parameters: compression efficiency, robustness, and
     compression transparency. A robust scheme tolerates loss and
     residual errors on the link over which header compression takes
     place without losing additional packets or introducing additional
     errors in decompressed headers.

3. Background

   This session provides a background to the subject of TCP/IP header
   compression. The fundamentals of general header compression had been
   introduced in [RFC3095]. Here two existing TCP/IP header compression
   schemes are described. Their drawbacks are then discussed, following
   by the classification of TCP/IP header fields. After that, the
   characteristics of the short-lived TCP transfers are discussed,
   following by the behavior analysis of TCP/IP header fields among
   multiple short-lived connections.

3.1 Existing TCP/IP header compression schemes

   There are two typical existing TCP/IP header compression schemes,
   which are VJHC [VJHC] and IPHC [IPHC], respectively. Both of them
   rely on transmitting only the difference from the previous header in
   order to reduce the large overhead of TCP/IP header.

   Although VJHC works well over reliable links, it is vulnerable on
   lossy links, because even a single bit error results in loss of
   synchronization between the compressor and decompressor. Considering
   the high bit error rate in cellular links, when used over unreliable
   links, it induces many additional errors due to inconsistent
   contexts between the compressor and the decompressor. Then the
   decompressor must send the request for resynchronization and in the
   meanwhile discard all compressed header. A fatal result of this
   effect is that it prevents TCP Fast Retransmit algorithm [E2E] from
   being fired and always causes TCP retransmission timeout. This
   effect is shown in detail in [MOBI96].

   IPHC proposes two simple mechanisms, the TWICE algorithm and the
   full header request mechanism, to reduce the errors due to the
   inconsistent contexts between the compressor and the decompressor.
   The TWICE algorithm assumes that only the Sequence Number field of
   TCP segments are changing during the connection and the deltas among
   consecutive packets are constant in most cases. However, these
   assumptions are not always true, especially when TCP Timestamp and
   SACK options are used. The full header request mechanism uses
   explicit request for retransmission of an uncompressed packet to
   allow resynchronization without waiting for a TCP timeout. It needs
   a feedback channel, which is unavailable in some circumstances. Even
   when the feedback channel is available, this mechanism still cannot
   perform well enough if the roundtrip time of this link is very long.
   Once a packet is corrupted on the noisy link, there are still
   several consecutive packets dropped due to the inconsistency between
   the compressor and the decompressor.

Zhang (ed.), et al.                                           [Page 7]

                       draft-ietf-rohc-tcp-02.txt



   Meanwhile, both IPHC and VJHC had not compressed the headers of
   handshaking packets (SYNs and FINs), and lack proper handling of TCP
   option fields (e.g., SACK or timestamps).

3.2 Classification of header fields

   Header compression is possible due to the fact that there is much
   redundancy between header field values within packets, especially
   between consecutive packets. To utilize these properties for header
   compression, it is important to understand the change patterns of
   the various header fields.

   All header fields have been classified in detail in Appendix A. The
   fields are first classified at a high level and then some of them
   are studied more in detail. Finally, the appendix concludes with
   recommendations on how the various fields should be handled by
   header compression algorithms. The main conclusion that can be drawn
   is that most of the header fields can easily be compressed away
   since they never or seldom change. Only several fields need more
   sophisticated mechanisms. These fields are:

       - IPv4 Identification (16 bits)         - IP-ID
        - TCP Sequence Number (32 bits)         - SN
        - TCP Acknowledgement Number (32 bits)  - ACKN
        - TCP Reserved (4 bits)
        - TCP ECN flags (2 bits)                - ECN
        - TCP Window (16 bits)                  - WINDOW
        - TCP Options
          - Maximum Segment Size (4 octets)    - MSS
          - Window Scale (3 octets)            - WSopt
           - SACK Permitted (2 octets)
           - TCP SACK                           - SACK
          - TCP Timestamp (32 bits)            - TS

   It is known that the change patterns of several TCP fields (for
   example, Sequence Number, Acknowledgement Number, Window, etc.) are
   completely different from the ones of RTP, which had already
   discussed in detail in [RFC3095], and are very hard to predict. The
   analysis in Appendix A reveals that an understanding of the sequence
   and acknowledgement number behaviors is essential for a TCP
   compression scheme.

   Note that at any point on the path (i.e. wherever a compressor might
   be deployed), the sequence number can be anywhere within a range
   defined by the TCP window. Missing packets or retransmissions can
   cause the TCP sequence number to fluctuate within the limits of this
   window. The jumps in acknowledgement number are also bounded by this
   TCP window.

   The dependency between sequence number and acknowledgement number
   had been mentioned in Appendix A. It's well-known that most TCP
   connections only have one-way traffic (for example, web browsing and

Zhang (ed.), et al.                                           [Page 8]

                       draft-ietf-rohc-tcp-02.txt


   FTP downloading). That is, on the forward path (from server to
   client), only Sequence Number changes and Acknowledgement Number
   remains constant at most time; on the backward path (from client to
   server), only Acknowledgement Number changes and Sequence Number
   remain constant at most time.

   The analysis in Appendix A also reveals that in the TCP case, there
   is no obvious candidate for a field to offer the Master sequence
   number to compress IP-ID field than in the RTP case. The assignment
   of IP-ID values can be done in various ways, which are Sequential
   jump, Random, and Sequential, respectively. However, designers of
   IPv4 stacks for cellular terminals SHOULD use an assignment policy
   close to sequential.

   An interesting thing for TCP options is that, most TCP options, such
   as MSS, WSopt, SACK-Permitted, etc., may appear only on a SYN
   segment. Every implementation should (and we expect that most will)
   ignore unknown options on SYN segments.

   Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
   special treatment in this document. They are compressible, however,
   and it is expected that the compression efficiency for Mobile IP
   headers will be good enough due to the handling of extension header
   lists and tunneling headers. The handling of this issue is conforms
   to [RFC3095].

3.3 Characteristics of the short-lived TCP transfers

   There are commonly cases where there will be multiple short-live TCP
   connections between the same cellular links. Two types of scenarios
   are given as examples, which can be illustrated in Figure 3.3.1. and
   Figure 3.3.2.

    Mobile             Base
   Terminals          Station                       Server

         |             \ /
      +---+   ~   ~   ~  |
      |   |    . . .     |                         +---------+
     |MT |              | ======================= | Server  |
      +---+   ~   ~   ~  |                         +---------+

           Cellular Link        Wired Network

     Figure 3.3.1. : Scenario for multiple connections between the same
               mobile terminal and server over cellular links

   In Figure 3.3.1., mobile terminal is connected to base station over
   cellular link, and the base station is connected to a server through
   wired (or possibly wireless) networks. There are multiple
   connections between the mobile terminal and the server
   simultaneously or near simultaneously (open within a relatively
   short space of time).

Zhang (ed.), et al.                                           [Page 9]

                       draft-ietf-rohc-tcp-02.txt



   In Figure 3.3.2., one mobile terminal is connected to base station
   over cellular link, and the base station is connected to multiple
   web servers through wired (or possibly wireless) networks. User in
   the mobile terminal may send multiple requests to different web
   servers simultaneously or near simultaneously.

    Mobile            Base                      Web
   Terminal          Station                   Servers
                                                     +----------+
         |  ~   ~   ~  \ /           ||============= | Server 1 |
         |              |            ||              +----------+
     +---+              |            ||
     |MT |              |            ||              . . . . . .
     |   |              |            ||
     +---+              |            ||
                        |            ||              +----------+
                        |============||============= | Server n |
                                                     +----------+
         Cellular Link           Wired Network

       Figure 3.3.2. : Scenario for mobile terminal send requests to
                  multiple web servers over cellular links

   For multiple connections with same source-IP, which occur
   simultaneously or near simultaneously, the IP header part of the
   contexts will probably be quite similar. Certain aspects of the TCP
   context may also be similar.

   For example, it may be that one of the port numbers will stay the
   same (the service port) and the other will change by a small amount
   relative to the just-closed connection (the ephemeral port).

   Short-lived TCP transfers will degrade the performances of header
   compression schemes which establish a new context by sending full
   headers initially. The way ROHC TCP compression operates, then, is
   to replicate the context among the short-live TCP flows so as to
   improve the compression efficiency.

   The new connection initializes a new context, (partially) copied the
   context from an existing one, and send out partial uncompressed
   packet to indicate the fields that need to be updated in the new
   context.

3.4 Classification of replicable header fields

   Context replication is possible due to the fact that there is much
   similarity in header field values and context values among multiple
   simultaneously or near simultaneously short-lived connections. To
   utilize these properties for header compression, it is important to
   understand the replicable characteristics for the various header
   fields and context values.


Zhang (ed.), et al.                                          [Page 10]

                       draft-ietf-rohc-tcp-02.txt


   All header fields and related context values have been classified in
   detail in appendix A. The main conclusion that can be drawn is that
   most part of the IP sub-context, some TCP fields, and some context
   values can easily be replicated since they seldom change or change
   with only a small jump. These fields are:

   IPv4 Header (inner and/or outer)

   Field                   Class           Replicable
   ------------------------------------------------
   Header Length           STATIC-KNOWN    Yes
   ToS                     CHANGING        Yes
   Packet Length           INFERRED        N/A
   Identification          CHANGING        Yes
   Time To Live            CHANGING        Yes
   Protocol                STATIC          N/A
   Header Checksum         INFERRED        N/A
   Source Address          STATIC-DEF      N/A
   Destination Address     STATIC-DEF      N/A

   IPv6 Header (inner and/or outer)

   Field                   Class           Replicable
   ------------------------------------------------
   Version                 STATIC          N/A
   Traffic Class           CHANGING        Yes
   Flow Label              STATIC-DEF      N/A
   Payload Length          INFERRED        N/A
   Next Header             STATIC          N/A
   Hop Limit               CHANGING        Yes
   Source Address          STATIC-DEF      N/A
   Destination Address     STATIC-DEF      N/A

   TCP Header

   Field                   Class           Replicable
   ------------------------------------------------
   Source Port             STATIC-DEF      Yes
   Destination Port        STATIC-DEF      Yes
   Data Offset             INFERRED        N/A
   Window                  CHANGING        Yes
   Reserved Bits           CHANGING        Yes
   Init-Window (Context)   CHANGING        Yes

   TCP Options

   Option                         SYN-only    Replicable
   -----------------------------------------------------
   Maximum Segment Size Option    Yes            Yes
   Window Scale Option            Yes            Yes
   SACK-Permitted Option          Yes            Yes
   Timestamps Option              No             Yes


Zhang (ed.), et al.                                          [Page 11]

                       draft-ietf-rohc-tcp-02.txt


4. TCP/IP header compression framework

   Similar to the ROHC framework, the ROHC-TCP protocol achieves its
   compression gain by establishing state information at both ends of
   the link, i.e., at the compressor and at the decompressor.

4.1 Compression and decompression states

   Header compression with ROHC can be characterized as an interaction
   between two state machines, one compressor machine and one
   decompressor machine, each instantiated once per context. The
   compressor and the decompressor have three and two states,
   respectively. Both machines start in the lowest compression state
   and transit gradually to higher states. Transitions need not be
   synchronized between the two machines. The compressor transits back
   to lower states when it does not have sufficient confidence to stay
   at the high state. The decompressor will transit back only when
   context damage is detected.

   Subsequent sections present an overview of the state machines and
   their corresponding states, respectively, starting with the
   compressor.

4.1.1 Compressor states

   There are three compressor states in ROHC-TCP: Initialization and
   Refresh (IR) state, First Order (FO), and Second Order (SO) states.
   The compressor starts in the lowest compression state (IR) and
   transits gradually to the higher compression state. The compressor
   will always operate in the highest possible compression state, under
   the constraint that the compressor is sufficiently confident that
   the decompressor has the information necessary to decompress a
   header, which is compressed according to the state.

                              +----------+
    +----------+  <-------->  | FO State |  <-------->  +----------+
    | IR State |              +----------+              | SO State |
    +----------+  <---------------------------------->  +----------+

   Decisions about transitions between the various compression states
   are taken by the compressor on the basis of:

      - variations in packet headers
      - positive feedback from decompressor (Acknowledgments -- ACKs)
      - negative feedback from decompressor (Negative ACKs -- NACKs)
      - robustness confidence level decision

   How transitions are performed is explained in detail in session 5.7
   for each mode of operation.

4.1.1.1. Initialization and Refresh (IR) state


Zhang (ed.), et al.                                          [Page 12]

                       draft-ietf-rohc-tcp-02.txt


   The purpose of IR state is to initialize or refresh the static parts
   of the context at the decompressor. In this state, the compressor
   sends full header (or partial full header) periodically. The
   compressor leaves the IR state only when it is confident that the
   decompressor has correctly received the static information.

4.1.1.2. First Order (FO) State

   The purpose of FO state is to efficiently transmit the difference
   between the two consecutive packets in the TCP stream. When
   operating in this state, the compressor and the decompressor should
   have the same context. Only compressed packet is transmitted from
   the compressor to the decompressor in this state. The compressor
   transits back to IR state only when it finds that the context of
   decompressor may be inconsistent, or there are remarkable changes in
   the TCP/IP header.

4.1.1.3. Second Order (SO) State

   The purpose of SO state is to efficiently transmit the fixed-payload
   data. The compressor enters this state when it is sufficiently
   confident that the decompressor has got the constant payload size of
   the data transferring.

   The compressor leaves this state and transits to the FO state when
   the current payload size no longer conforms to the constant payload.
   The compressor transits back to IR state only when it finds that the
   context of decompressor may be inconsistent, or there are remarkable
   changes in the TCP/IP header.

4.1.2. Decompressor states

   The decompressor starts in its lowest compression state, "No
   Context" and gradually transits to higher state, "Full Context". The
   decompressor state machine normally never leaves the "Full Context"
   state once it has entered this state.

          +--------------+         +--------------+
          |  No Context  |  <--->  | Full Context |
          +--------------+         +--------------+

   Initially, while working in the "No Context" state, the decompressor
   has not yet successfully decompressed a packet. Once a packet has
   been decompressed correctly, the decompressor can transit to the
   "Full Context" state, and only upon repeated failures will it
   transit back to lower state.

   When state transitions are performed is explained in detail in
   session 5.7.

4.2 Modes of operation


Zhang (ed.), et al.                                          [Page 13]

                       draft-ietf-rohc-tcp-02.txt


   There are two modes in ROHC-TCP, called Unidirectional and Bi-
   directional mode (U-mode and B-mode), respectively. The mode
   transitions are conformed to ROHC framework. However, the operations
   of each mode are different.

4.2.1. Unidirectional mode -- U-mode

   When in U-mode, packets are sent in one direction only: from
   compressor to decompressor. Therefore, feedbacks from decompressor
   to the compressor are unavailable under this mode.

   In U-mode, transitions between compressor states are performed only
   on account of the robustness confidence level and irregularities in
   the header field change patterns in the compressed packet stream.
   The error detection and error recovery relies on the TCP protocol
   itself. Due to the lack of feedback for correctness acknowledgement
   and initiation of error recovery, compression in the U-mode will be
   less efficient.

   Compression with ROHC-TCP MUST starts in the U-mode. Transition to
   the B-mode can be performed as soon as a packet has reached the
   decompressor and it has replied with a feedback packet indicating
   that a mode transition is desired (see session 5.7).

4.2.2. Bi-directional mode -- B-mode

   The Bidirectional mode is similar to the Unidirectional mode. The
   difference is that a feedback channel is used to send error recovery
   requests and (optionally) acknowledgments of significant context
   updates from decompressor to compressor (not, however, for pure
   sequence number updates). In this mode, the number of context
   updates can be reduced more efficiently.

   B-mode aims to maximize compression efficiency and sparse usage of
   the feedback channel. The frequency of context invalidation may be
   lower than for U-mode.

4.3. Impairment considerations

   Impairments to headers can be classified into the following types:

   (1) the lower layer was not able to decode the packet and did not
        deliver it to ROHC,

   (2) the lower layer was able to decode the packet, but discarded it
        because of a detected error,

   (3) ROHC detected an error in the generated header and discarded the
        packet, or

   (4) ROHC did not detect that the regenerated header was damaged and
        delivered it to upper layers.


Zhang (ed.), et al.                                          [Page 14]

                       draft-ietf-rohc-tcp-02.txt


   Impairments cause loss of individual headers. Some impairment
   scenarios also cause context invalidation, which in turn results in
   loss propagation. Loss propagation and impairments resulting in loss
   or discarding of single packets both contribute to the packet loss
   seen by upper layers.

   Examples of context invalidating scenarios are:

   (a) Impairment of type (4) on the forward channel, causing the
        decompressor to update its context with incorrect information;

   (b) Loss/error burst of headers: Impairments of types (1), (2) and
        (3) on a number of consecutive headers that is large enough to
        cause the decompressor to lose the context synchronization;

   Scenario (a) is mitigated by the CRC carried in all headers. The
   larger the CRC, the lower the chance of context invalidation caused
   by (a). The CRC of headers is usually 3 bits and sometimes 7 or 8
   bits.

   Scenario (b) is mitigated by the CRC check.

   ROHC detects damaged headers using CRCs over the original headers.
   The smallest headers in this document include a 3-bit CRC. For the
   smallest headers, damage is thus detected with a probability of
   roughly 7/8.

   The above analysis suggests that U-mode may be more prone than B-
   mode to context invalidation. On the other hand, the CRC present in
   all U/B-mode headers permits quick detection of context invalidation.

5. The Protocol

5.1. Data structures

   As stated in [RFC3095], the ROHC protocol is based on a number of
   parameters that form part of the negotiated channel state and the
   per-context state. For ROHC-TCP case, some parameters in Per-channel
   and Per-context need to be modified.

   PROFILES in Per-channel parameter:
       Define a unique nonnegative integer to indicate the TCP/IP
       profile supported by the decompressor. The compressor MUST NOT
       compress using a profile not in PROFILES.

   Profiles in Per-context parameter:
       Profile 0x0005 is for TCP/IP compression.

5.2. ROHC-TCP packet formats from compressor to decompressor

   ROHC-TCP uses four packet types to identify compressed headers, and
   three for initialization/refresh/replication. The format of a
   compressed packet does not depend on the mode.

Zhang (ed.), et al.                                          [Page 15]

                       draft-ietf-rohc-tcp-02.txt



   Packet type: IR

   This packet type communicates the static part of the context. It can
   optionally also communicate the dynamic part of the context.

   Packet type: IR-DYN

   This packet type communicates the dynamic part of the context.

   Packet type: IR-REPLICATE

   This packet type communicates the static and dynamic parts of the
   replicated context.

5.3. Parameters needed for mode transition in ROHC-TCP

   The packet types IR (with dynamic information), IR-DYN, and IR-
   REPLICATE are common for all modes.

   Feedback of types ACK, NACK carry master sequence number, and
   feedback packets can also carry a mode parameter indicating the
   desired compression mode: U or B.

   As a shorthand, the notation PACKET(mode) is used to indicate which
   mode value a packet carries. For example, an ACK with mode parameter
   B is written ACK(B).

5.4 Robustness and efficiency maintenance

   Considering the changing pattern of several TCP fields, Window-based
   LSB encoding [RFC3095], which does not assume the linear changing
   pattern of the target header fields, is more suitable to encode
   those TCP fields both efficiently and robustly.

   Using ROHC-TCP, the compressor and decompressor maintain a context
   value. To provide robustness, the compressor can maintain more than
   one context value for each field. These values represent the r most
   likely candidates' values for the context at the decompressor.

   ROHC-TCP ensures that the compressed header contains enough
   information so that the uncompressed header can be extracted no
   matter which one of the compressor context values is actually stored
   at the decompressor. The only problem arises if the decompressor has
   a context value that does not belong to the set of values stored at
   the compressor; this situation is detected by a CRC over the
   uncompressed header and the packet is discarded at the decompressor.

   If more than one value for a field is stored in the compressor
   context, W-LSB encoding will only succeed if sufficient LSBs are
   sent to infer correct value of the field regardless of the precise
   value stored in the decompressor context.


Zhang (ed.), et al.                                          [Page 16]

                       draft-ietf-rohc-tcp-02.txt


   Storing more context values at the compressor reduces the chance
   that the decompressor will have a context value different from any
   of the values stored at the compressor (which could cause the packet
   to be decompressed incorrectly).

   As an example, an implementation may choose to store the last r
   values of each field in the compressor context. In this case
   robustness is guaranteed against up to r - 1 consecutive dropped
   packets between the compressor and the decompressor. Thus, by
   keeping the value r large enough, the compressor rarely gets out of
   synchronization with the decompressor.

   However, the trade-off is that the larger the number of context
   values is, the compressed header will be larger because it must
   contain enough information to decompress relative to any of the
   candidate context values.

   To reduce the number of context value r, the compressor needs some
   form of feedback to get sufficient confidence that a certain context
   value will not be used as a reference by the decompressor. Then the
   compressor can remove that value and all other values older than it
   from its context. Obviously, when a feedback channel is available,
   confidence can be achieved by proactive feedback in the form of ACKs
   from the decompressor. A feedback channel, however, is unavailable
   or expensive in some environments. For TCP/IP header compression, an
   implicit feedback can be obtained from the nature feedback-loop of
   TCP protocol itself.

   Since TCP is a window-based protocol, a new segment cannot be
   transmitted without getting the acknowledgment of segment in the
   previous window. Upon receiving the new segment, the compressor can
   get enough confidence that the decompressor has received the segment
   in the previous window and then shrink the context window by
   removing all the values older than that segment.

   This is to say, the context window of ROHC-TCP, the number of
   context value r, can be controlled by the TCP congestion window.

   How to estimate TCP congestion window is an implementation issue
   that can be determined by the compressor. A tracking based TCP
   congestion window estimation algorithm is discussed in the Section
   5.9.4 as an optional enhancement for the compressor.

5.5 Operation in U-mode

5.5.1. Compressor state and logic

   Below is the state machine for the compressor in U-mode. Details of
   the transitions between states and compression logic are given
   subsequent to the following figure.

                            Optimistic approach
     +------>------>------>------>------>------>------>------>------+

Zhang (ed.), et al.                                          [Page 17]

                       draft-ietf-rohc-tcp-02.txt


     |                                                              |
     |        Optimistic approach        Optimistic approach        |
     |      +------>------>------+      +------>------>------+      |
     |      |                    |      |                    |      |
     |      |                    v      |                    v      v
   +----------+                +----------+                +----------+
   | IR State |                | FO State |                | SO State |
   +----------+                +----------+                +----------+
     ^      ^                    |      ^                    |      |
     |      |      Update        |      |        Update      |      |
     |      +------<------<------+      +------<------<------+      |
     |                                                              |
     |                           Update                             |
     +------<------<------<------<------<------<------<------<------+

5.5.1.1. State transition logic (U-mode)

   The transition logic for compression states in U-mode is based on
   two principles: the optimistic approach principle and the need for
   update.

   In ROHC-TCP, the compressor will start in the IR state and perform
   different logics in different states. The following sub-sections
   will describe the logic for each compressor sate in detail.

5.5.1.1.1. Optimistic approach, upwards transition

   Transition to a higher compression state in U-mode is carried out
   according to the optimistic approach principle. This means that the
   compressor transits to a higher compression state when it is fairly
   confident that the decompressor has received enough information to
   correctly decompress packets sent according to the higher
   compression state.

   When the compressor is in the IR state, it will stay there until it
   assumes that the decompressor has correctly received the context
   information. For transition from the FO to the SO state, the
   compressor should be confident that the decompressor has all
   parameters needed to decompressed according to a fixed payload
   pattern.

   In general, there are many approaches where the compressor can
   obtain such information. A simple and general approach can be
   sending uncompressed or partial full headers periodically. The
   following subsections describe some optional approaches, which
   utilizing the TCP specific behavior to obtain better performance.

5.5.1.1.1.1. Optional transition for short-live TCP transfers

   This approach is introduced in ROHC-TCP to compress short-lived TCP
   transfers more efficiently.


Zhang (ed.), et al.                                          [Page 18]

                       draft-ietf-rohc-tcp-02.txt


   The key message of this approach is that the compressor should try
   to speed up the initialization process. This approach can be applied
   if the compressor is able to see the SYN packet. The compressor
   enters the IR state when it receives the packet with SYN bit set and
   sends IR packet. When it receives the first data packet of the
   transfer, it should transit to FO state because that means the
   decompressor has received the packet with SYN bit set and
   established the context successfully at its side. Using this
   mechanism can significantly reduce the number of context initiation
   headers.

5.5.1.1.1.2. Optional operation in IR state

   In IR state, the compressor can send full header (or partial full
   header) periodically with an exponentially increasing period, which
   is so-called compression slow-start [IPHC].

   The main idea of this optional operation is controlling the size of
   context window by dynamically TCP congestion window estimation.

   After a packet has been sent out, the compressor invokes the
   Algorithm SEQ and Algorithm ACK introduced in Session 5.9. to track
   the congestion windows of the two one-way traffics with different
   directions in a TCP connection. Suppose that the estimated
   congestion windows are cwnd_seq and cwnd_ack, while the estimated
   slow start thresholds are ssthresh_seq and ssthresh_ack,
   respectively. Let

       W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
             K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
                   MAX(cwnd_ack, 2*ssthresh_ack)).

   If the value of context window, r, is larger than W(cwnd_seq,
   ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is an
   implementation parameter that will be further discussed in Section
   5.9.

   If the number of the compress packets been send gets larger than
   W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the compressor
   transits to FO/SO state.

   If the compressor finds that the payload size of consecutive packets
   is a constant value and one of such packets is removed from the
   context window, which means the decompressor has known the exact
   value of the constant size, it may transit to SO state. Otherwise it
   will transit to the FO state.

   If the compressor transits to the IR state from the higher states,
   the compressor will re-initialize the algorithm for tracking TCP
   congestion window.

5.5.1.1.1.3. Optional operation in FO state


Zhang (ed.), et al.                                          [Page 19]

                       draft-ietf-rohc-tcp-02.txt


   After a packet has been sent out, the compressor invokes the
   Algorithm SEQ and Algorithm ACK introduced in Session 5.9., to track
   the congestion windows of the two one-way traffics with different
   directions in a TCP connection. Suppose that the estimated
   congestion windows are cwnd_seq and cwnd_ack, while the estimated
   slow start thresholds are ssthresh_seq and ssthresh_ack,
   respectively. Let

       W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
             K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
                   MAX(cwnd_ack, 2*ssthresh_ack)).

   If the value of context window, r, is larger than W(cwnd_seq,
   ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is an
   implementation parameter, which can be set to the same value as in
   the IR state.

   If the compressor finds that the payload size of consecutive packets
   is a constant value and one of such packets has been removed from
   the context window, which means the decompressor has known the exact
   value of the constant size, it may transit to the SO state.

5.5.1.1.2. Need for update, downwards transition

   When the header to be compressed does not conform to the established
   pattern or the compressor is not confident whether the decompressor
   has the synchronized context, the compressor will transit to the
   lower compression state.

   In general, there are many approaches where the compressor can
   obtain such information. A simple and general approach can be
   transiting to the lower compression state periodically. The
   following subsections describe some optional approaches, which
   utilizing the TCP specific behavior to achieve better performance.

5.5.1.1.2.1 Optional operation for downwards transition

   The compressor must immediately transit back to the IR state when
   the header to be compressed, falls behind the context window, i.e.
   it is older than all the packets in context.

   If the context window contains only one packet, which means there is
   a long jump in the packet sequence number or acknowledge number, the
   compressor will transit to the IR state. Here, a segment causes a
   long jump when the distance between its sequence number (or
   acknowledgment number) and CMAXSN (or CMAXACK) is larger than the
   estimated congestion window size, i.e.,

     |sequence number (acknowledgement number) - CMAXSN (CMAXACK)| >
                  estimated congestion window size.

5.5.1.1.2.2. Optional operation in SO state


Zhang (ed.), et al.                                          [Page 20]

                       draft-ietf-rohc-tcp-02.txt


   After a packet has been sent out, the compressor invokes the
   Algorithm SEQ and Algorithm ACK to track the congestion windows of
   the two one-way traffics with different directions in a TCP
   connection. Suppose that the estimated congestion windows are
   cwnd_seq and cwnd_ack, while the estimated slow start thresholds are
   ssthresh_seq and ssthresh_ack, respectively. Let

   W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) =
          K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
                MAX(cwnd_ack, 2*ssthresh_ack)).

   If the value of context window, r, is larger than W(cwnd_seq,
   ssthresh_seq, cwnd_ack, ssthresh_ack), r can be reduced. K is an
   implementation parameter, which can be set to the same value as in
   the IR state.

   If the payload size of the packets in context window doesn't keep
   constant, the compressor transits to the FO state.

5.5.2. Decompressor logic

   The logic of the decompressor is simpler compared to the compressor.

5.5.2.1. No Context State

   The decompressor starts in this state. Upon receiving an IR, IR-DYN
   or IR-REPLICATE packet, the decompressor should first verify the
   correctness of this packet. Then it will determine that whether this
   is an IR-REPLICATE packet. For an IR-REPLICATE packet, the
   decompressor will re-build a new context from the existing one and
   make the necessary update. Otherwise, the decompressor will just
   update the context. Finally, the decompressor will use this packet
   as the reference packet.

   After that, the decompressor will pass the packet to the system's
   network layer and transit to Full Context state. Conformed to ROHC
   framework [RFC3095], only IR, IR-DYN or IR-REPLICATE packets may be
   decompressed in No Context state.

5.5.2.2. Full Context State

   The operations of decompressor in Full Context state can be
   summarized as follows:

   a) Upon receiving an IR, IR-DYN or IR-REPLICATE packet, the
   decompressor should verify the correctness of its header by CRC
   check. If the verification succeeds, the decompressor will update
   the context and use this packet as the reference packet.
   Consequently, the decompressor will convert the packet into the
   original packet and pass it to the network layer of the system.

   b) Upon receiving the other type of packet, the decompressor will
   decompress it. After that, the decompressor MUST verify the

Zhang (ed.), et al.                                          [Page 21]

                       draft-ietf-rohc-tcp-02.txt


   correctness of the decompressed packet. If the verification succeeds,
   the decompressor passes it to the system's network layer. Then the
   decompressor will use it as the reference value if this packet is
   not older than the current reference packet by checking MSN or
   sequence number and/or acknowledgement number field in TCP header.

   c) If consequent N packets fail to be decompressed, the decompressor
   should transit downwards to No Context state. N is an implementation
   parameter that will be further discussed in Section 5.9.

5.6. Operations in B-mode

5.6.1. Compressor states and logic

                           Optimistic approach / ACK
     +------>------>------>------>------>------>------>------>------+
     |                                                              |
     |      Optimistic appr. / ACK      Optimistic appr. /ACK   ACK |
     |      +------>------>------+      +------>--- -->-----+  +->--+
     |      |                    |      |                   |  |    |
     |      |                    v      |                   v  |    v
   +----------+                +----------+                +----------+
   | IR State |                | FO State |                | SO State |
   +----------+                +----------+                +----------+
     ^      ^                    |      ^                    |      |
     |      |    NACK / Update   |      |       Update       |      |
     |      +------<------<------+      +------<------<------+      |
     |                                                              |
     |                         NACK / Update                        |
      +------<------<------<------<------<------<------<------<------+

   Below is the state machine for the compressor in B-mode. The details
   of each state, state transitions and compression logic are given
   subsequent to the figure.

   The B-mode makes use of feedback from decompressor to compressor for
   OPTIONAL improving the transitions among different states. Feedback
   packet types ACK and NACK are conform to the ones defined in
   [RFC3095].

5.6.1.1. Master Sequence Number (MSN) for packet acknowledging

   Feedback of types ACK and NACK carry the information about sequence
   number/ acknowledgement number from decompressor to the compressor.
   Unfortunately, sequence number/acknowledgement number field is not
   guaranteed to be present in every IP protocol stack. Meanwhile, the
   size of the sequence number/acknowledgement number field is rather
   large, which is not so efficient if it is carried in the feedback
   packet directly. To overcome this problem ROHC-TCP introduces a
   control field called the Master Sequence Number (MSN) field. This
   field is present in every m compressed header and can be used to
   infer the acknowledged sequence number.


Zhang (ed.), et al.                                          [Page 22]

                       draft-ietf-rohc-tcp-02.txt


   The value of m is chosen for the best trade-off between compression
   efficiency and the acknowledging efficiency.

5.6.1.2. State transition logic

   The transition logic for compression states in B-mode has much in
   common with the logic of the U-mode. The optimistic approach
   principles and transitions occasioned by the need for update work in
   the same way as described in session 5.5.1. However, the B-mode
   makes use of feedback from decompressor to compressor for
   transitions in the backward direction and for OPTIONAL improved
   forward transition.

5.6.1.2.1. Negative acknowledgments (NACKs), downward transition

   Negative acknowledgments (NACKs) are also called context requests.
   Upon reception of a NACK the compressor transits back to the IR
   state and sends updates (IR-DYN, or possibly IR or IR-REPLICATE) to
   the decompressor. NACKs carry the MSN of the latest packet
   successfully decompressed.

5.6.1.2.2. Optional acknowledgments, upwards transition

   In addition to NACKs, positive feedback (ACKs) MAY also be used for
   packets in the B-mode. Upon reception of an ACK for an updating
   packet, the compressor knows that the decompressor has received the
   acknowledged packet and the transition to a higher compression state
   can be carried out immediately. This functionality is optional, so a
   compressor MUST NOT expect to get such ACKs initially.

5.6.1.3. Compression logic and packets used

   The compression logic is the same for the B-mode as for the U-mode
   (see section 5.5.1.).

   In the IR state, the compressor can transit to the FO or SO state
   once it receives a valid ACK(B) for an IR/IR-REPLICATE packet sent
   (an ACK(B) can only be valid if it refers to a packet sent earlier).
   If the packet referred by the feedback is in the context window, the
   compressor will remove the packets older than the referred packet
   from the context window. Because ACK(B) means that the packet
   referred by feedback has been the reference of the decompressor, the
   compressor doesn't need to keep older packets.

   If the compressor is in the FO or SO state, it will remove the
   packets older than the referred packet by the feedback from the
   context window.

   Upon receiving an NACK(B), the compressor transits back to IR state.

5.6.2. Decompressor states and logic


Zhang (ed.), et al.                                          [Page 23]

                       draft-ietf-rohc-tcp-02.txt


   The decompression states and the state transition logic are the same
   as in the U-mode (see section 5.2.2.). What differs is the feedback
   logic.

   When an IR or IR-REPLICATE packet passes the verification, the
   decompressor sends an ACK(B). When an IR-DYN packet or other packet
   is correctly decompressed, optionally send an ACK(B). In both cases,
   the feedback packet will carry the master sequence number
   information about the latest correctly decompressed packet with MSN.

   In the Full Context state, when the verification check of x out of
   the last y decompressed packets have failed, context damage SHOULD
   be assumed and a NACK(B) SHOULD be sent. The decompressor moves to
   the No Context state and discards all packets until an update which
   passes the verification check is received.

   Note that appropriate values for x and y, are related to the
   residual error rate of the link. When the residual error rate is
   close to zero, x = y = 1 may be appropriate.

   In the No Context state, when any packet fails the verification,
   send an NACK(B). The decompressor discards all packets until a
   static update (IR) or replication (IR-REPLICATE) which passes the
   verification check is received.

5.7. Mode transitions

   The decision to move from one compression mode to another is taken
   by the decompressor and the possible mode transitions are shown in
   the figure below. Subsequent sections describe how the transitions
   are performed together with exceptions for the compression and
   decompression functionality during transitions.

                         +-------------------------+
                         | Unidirectional (U) mode |
                         +-------------------------+
                                   | ^
                                   | | Feedback(U)
                                   | |
                       Feedback(B) | |
                                   v |
                         +-------------------------+
                         | Bidirectional (B) mode  |
                         +-------------------------+

5.7.1. Compression and decompression during mode transitions

   The following sections assume that, for each context, the compressor
   and decompressor maintain a variable whose value is the current
   compression mode for that context. The value of the variable
   controls, for the context in question, which actions to be taken,
   etc.


Zhang (ed.), et al.                                          [Page 24]

                       draft-ietf-rohc-tcp-02.txt


   As a safeguard against residual errors, all feedback sent during a
   mode transition MUST be protected by a CRC, i.e., the CRC option
   MUST be used. A mode transition MUST NOT be initiated by feedback
   which is not protected by a CRC.

   The subsequent subsections define exactly when to change the value
   of the MODE variable. All mode-related parameters are listed below
   together with their possible values, with explanations and
   restrictions:

   Parameters for the compressor side:

      - C_MODE:
         Possible values for the C_MODE parameter are (U)NIDIRECTIONAL,
         (B)IDIRECTIONAL. C_MODE MUST be initialized to U.

   Parameters for the decompressor side:

      - D_MODE:
         Possible values for the D_MODE parameter are (U)NIDIRECTIONAL
         and (B)IDIRECTIONAL.  D_MODE MUST be initialized to U.

5.7.2. Transition from Unidirectional to Bidirectional mode

   When there is a feedback channel available, the decompressor may at
   any moment decide to initiate transition from Unidirectional to
   Bidirectional mode. Any feedback packet carrying a CRC can be used
   with the mode parameter set to B. The decompressor can then directly
   start working in B-mode. The compressor transits from U-mode to B-
   mode as soon as it receives any feedback packet that has the mode
   parameter set to B and passes the CRC check. The transition
   procedure is described below:

              Compressor                     Decompressor
             ----------------------------------------------
                   |                               |
                   |        ACK(B)/NACK(B) +-<-<-<-|  D_MODE = B
                   |       +-<-<-<-<-<-<-<-+       |
   C_MODE = B      |-<-<-<-+                       |
                   |                               |

   If the feedback packet is lost, the compressor will continue to work
   in U-mode, but as soon as any feedback packet reaches the compressor
   it will transit to B-mode.

5.7.3. Transition to Unidirectional mode

   The decompressor may initiate a transition back to U-mode if it
   desires to do so. Any feedback packet carrying a CRC can be used
   with the mode parameter set to U. The decompressor can then directly
   start working in B-mode. The compressor transits from B-mode to U-
   mode as soon as it receives any feedback packet that has the mode

Zhang (ed.), et al.                                          [Page 25]

                       draft-ietf-rohc-tcp-02.txt


   parameter set to B and passes the CRC check. The transition
   procedure is described below:

              Compressor                     Decompressor
             ----------------------------------------------
               |                               |
               |        ACK(U)/NACK(U) +-<-<-<-| D_MODE = U
               |       +-<-<-<-<-<-<-<-+       |
   C_MODE = U  |-<-<-<-+                       |
               |                               |

   If the feedback packet is lost, the compressor will continue to work
   in B-mode, but as soon as there is no feedback for a long time
   (timeout), the compressor will transit to U-mode. The timeout is not
   defined in this document.

5.8. Context Replication

   Context replication can be considered as the mechanism which
   establishes a context based on another valid context already created,
   i.e. the base context. This mechanism will reduce the overhead of
   context establishment significantly, especially for short-lived TCP
   connections.

   For robustness, before sending IR-REPLICATE packet, the compressor
   must obtain enough confidence that the base context is sync with the
   decompressor's one otherwise the robustness will be reduced slowly
   due to the dependency of the base context. The most reliable way to
   select the base context is to choose only contexts in FO/SO state
   and acknowledged by the decompressor, i.e. only contexts in FO/SO
   state under B-mode can be used as base contexts.

   The operation during a context replication is described as follows:
   During the context establishment of a context (in IR state), each
   time an IR/IR-DYN need to be transmitted the compressor will send
   IR-REPLICATE if there are base contexts available. When the
   decompressor receives IR-REPLICATE packets, it will decompress it
   and send feedback accordingly.

5.9. Implementation optimizations

5.9.1. Determine the value N

   We should distinguish out of synchronization from the packet errors
   cause by the link. So considering the error condition of the link, N
   should be higher than the packet burst error length, a practical
   range of N is around 8~10.

5.9.2. Determine the frequency of updating context

   The choice of the frequency of updating context, ACK(B), is a
   balance between the efficiency and robustness, i.e. sending ACK(B)
   more frequently improves the compression robustness but adds more

Zhang (ed.), et al.                                          [Page 26]

                       draft-ietf-rohc-tcp-02.txt


   system overhead, and the vice versa. From a practical view, the
   ACK(B) SHOULD be sent for every 4~8 successfully decompressed
   packets.

5.9.3. Tracking-based TCP congestion window estimation

   As originally outlined in [CAC] and specified in [RFC2581], TCP is
   incorporated with four congestion control algorithms: slow-start,
   congestion-avoidance, fast retransmit, and fast recovery. The
   effective window of TCP is mainly controlled by the congestion
   window and may change during the entire connection life. ROHC-TCP
   designs a mechanism to track the dynamics of TCP congestion window,
   and control the number of context value r of windowed LSB encoding
   by the estimated congestion window. By combining the windowed LSB
   encoding and TCP congestion window tracking, ROHC-TCP can achieve
   better performance over high bit-error-rate links.

   Note that in one-way TCP traffic, only the information about
   sequence number or acknowledgment number is available for tracking
   TCP congestion window. ROHC-TCP does not require that all one-way
   TCP traffics must cross the same compressor. The detail will be
   described in the following sections.

5.9.3.1. General principle of congestion window tracking

   The general principle of congestion window tracking is as follows.
   The compressor imitates the congestion control behavior of TCP upon
   receiving each segment, in the meantime, estimates the congestion
   window (cwnd) and the slow start threshold (ssthresh). Besides the
   requirement of accuracy, there are also some other requirements for
   the congestion window tracking algorithms:

        - Simplex link. The tracking algorithm SHOULD always only take
        Sequence Number or Acknowledgment Number of a one-way TCP
        traffic into consideration. It SHOULD NOT use Sequence Number
        and Acknowledgment Number of that traffic simultaneously.

        - Misordering resilience. The tracking algorithm SHOULD work
        well while receiving misordered segments.

        - Multiple-links. The tracking algorithm SHOULD work well when
        not all the one-way TCP traffics are crossing the same link.

        - Slightly overestimation. If the tracking algorithm cannot
        guarantee the accuracy of the estimated cwnd and ssthresh, it is
        RECOMMANDED that it produces a slightly overestimated one.

   The following sections will describe two congestion window tracking
   algorithms, which use Sequence Number and Acknowledgment Number of a
   one-way TCP traffic, respectively.

5.9.3.2. Tracking based on Sequence Number


Zhang (ed.), et al.                                          [Page 27]

                       draft-ietf-rohc-tcp-02.txt


   This algorithm (Algorithm SEQ) contains 3 states: SLOW-START,
   CONGESTION-AVOIDANCE, and FAST-RECOVERY, which are equivalent to the
   states in TCP congestion control algorithms. It maintains 2
   variables: cwnd and ssthresh.

                                   +-------------+
                                   |             |
                  ---------------->| CONGESTION- |
                  |                |  AVOIDANCE  |
                  |            ----|             |<---
          +------------+       |   +-------------+   |
          |            |       |                     |
          | SLOW-START |       |                     |
          |            |       |   +-------------+   |
          +------------+       |   |             |   |
                  |            |-->|    FAST-    |----
                  |                |  RECOVERY   |
                  ---------------->|             |
                                   +-------------+


   Initially, this algorithm starts in state SLOW-START with ssthresh
   set to ISSTHRESH and cwnd set to IW.

   Upon receiving a segment, if it is the first segment, which is not
   necessary to be the SYN segment, the algorithm sets the current
   maximum Sequence Number (CMAXSN) and the current minimum Sequence
   Number (CMINSN) to this segment's sequence number; otherwise, the
   algorithm takes a procedure according to the current state.

     - SLOW-START

       * If the new Sequence Number (NSN) is larger than CMAXSN,
          increase cwnd by the distance between NSN and CMAXSN, and
          update CMAXSN and CMINSN based on the following rules:
              CMAXSN = NSN
              if (CMAXSN - CMINSN) > cwnd)
                  CMINSN = cwnd - CMAXSN;
          If the cwnd is larger than ssthresh, the algorithm transits to
          CONGESTION-AVOIDANCE state;

       * If the distance between NSN and CMAXSN is less than or equal
          to 3*MSS, ignore it;

       * If the distance is larger than 3*MSS, halve the cwnd and set
          ssthresh to MAX(cwnd, 2*MSS).  After that, the algorithm
          transits into FAST-RECOVERY state.

     - CONGESTION-AVOIDANCE

       * If NSN is larger than CMAXSN, increase cwnd by ((NSN-
          CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on
          the following rules:

Zhang (ed.), et al.                                          [Page 28]

                       draft-ietf-rohc-tcp-02.txt


              CMAXSN = NSN
              if (CMAXSN - CMINSN) > cwnd)
                  CMINSN = cwnd - CMAXSN;

       * If the distance between NSN and CMAXSN is less than or equal
          to 3*MSS, ignore it;

       * If the distance is larger than 3*MSS, halve the cwnd and set
          ssthresh to MAX(cwnd, 2*MSS).  After that, the algorithm
          transits into FAST-RECOVERY state.

     - FAST-RECOVERY

       * If NSN is larger than or equal to CMAXSN + cwnd, the algorithm
          transits into CONGESTION-AVOIDANCE state;

       * Otherwise, ignore it.

   In this algorithm, MSS is denoted as the estimated maximum segment
   size. The implementation can use the MTU of the link as an
   approximation of this value. ISSHRESH and IW are the initial values
   of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
   high. IW SHOULD be set to 4*MSS.


5.9.3.3. Tracking based on Acknowledgment Number

                                   +-------------+
                                   |             |
                  ---------------->| CONGESTION- |
                  |                |  AVOIDANCE  |
                  |            ----|             |<---
          +------------+       |   +-------------+   |
          |            |       |                     |
          | SLOW-START |       |                     |
          |            |       |   +-------------+   |
          +------------+       |   |             |   |
                  |            |-->|     FAST-   |----
                  |                |   RECOVERY  |
                  ---------------->|             |
                                   +-------------+

   This algorithm (Algorithm ACK) maintains 3 states: SLOW-START,
   CONGESTION-AVOIDANCE and FAST-RECOVERY, which are equivalent to the
   states in TCP congestion control algorithms. It also maintains 2
   variables: cwnd and ssthresh.

   Initially, this algorithm starts in state SLOW-START with ssthresh
   set to ISSTHRESH and cwnd set to IW.

   Upon receiving a segment, if it is the first segment, which is not
   necessary to be the SYN segment, the algorithm sets the current
   maximum Acknowledgment Number (CMAXACK) to this segment's

Zhang (ed.), et al.                                          [Page 29]

                       draft-ietf-rohc-tcp-02.txt


   acknowledgment number; otherwise, the algorithm takes a procedure
   according to the current state.

     - SLOW-START

       * If the new Acknowledgment Number (NEWACK) is larger than
          CMAXACK, increase cwnd by the distance between NEWACK and
          CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update
          CMAXACK accordingly; If the cwnd is larger than ssthresh, the
          algorithm transits to CONGESTION-AVOIDANCE state;

       * If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If
          NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
          MAX(cwnd, 2*MSS). Consequently, the algorithm transits into
          FAST-RECOVERY state;

       * Otherwise, set NDUPACKS to 0.

     - CONGESTION-AVOIDANCE

       * If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK-
          CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK
          accordingly;

       * If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If
          NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
          MAX(cwnd, 2*MSS). After that, the algorithm transits into
          FAST-RECOVERY state;

       * Otherwise, set NDUPACKS to 0.

     - FAST-RECOVERY

       * If NEWACK is larger than CMAXACK, set NDUPACKS to 0.
          Consequently, the algorithm transits into CONGESTION-AVOID
          state;

       * Otherwise, ignore it.

   In this algorithm, MSS is denoted as the estimated maximum segment
   size. The implementation can use the MTU of the link as an
   approximation of this value. ISSHRESH and IW are the initial values
   of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
   high. IW SHOULD be set to 4*MSS.


5.9.3.4. Further discussion on congestion window tracking

   In some cases, it is inevitable for the tracking algorithms to
   overestimate the TCP congestion window. Also, it SHOULD be avoided
   that the estimated congestion window gets significantly smaller that
   the actual one. For all of these cases, ROHC-TCP simply applies two
   boundaries on the estimated congestion window size. One of the two

Zhang (ed.), et al.                                          [Page 30]

                       draft-ietf-rohc-tcp-02.txt


   boundaries is the MIN boundary, which is the minimum congestion
   window size and whose value is determined according to the [INITWIN];
   the other boundary is the MAX boundary, which is the maximum
   congestion window size. There are two possible approaches to setting
   this MAX boundary. One is to select a commonly used maximum TCP
   socket buffer size. The other one is to use the simple equation
   W=sqrt(8/3*l), where W is the maximum window size and l is the
   typical packet loss rate.

   If ECN mechanism is deployed, according to [RFC2481] and [ECN], the
   TCP sender will set the CWR (Congestion Window Reduced) flag in the
   TCP header of the first new data packet sent after the window
   reduction, and the TCP receiver will reset the ECN-Echo flag back to
   0 after receiving a packet with CWR flag set. Thus, the CWR flag and
   the ECN-Echo flag's transition from 1 to 0 can be used as another
   indication of congestion combined with other mechanisms mentioned in
   the tracking algorithm.

5.9.3.5. Determine the value K in congestion window estimation

   As mentioned above, the context window SHOULD be shrunk when its
   size gets larger than K*MAX(MAX(cwnd_seq, 2*ssthresh_seq),
   MAX(cwnd_ack, 2*ssthresh_ack)). Since the Fast Recovery algorithm
   was introduced in TCP, several TCP variants had been proposed, which
   are different only in the behaviors of Fast Recovery. Some of them
   need several RTTs to be recovered from multiple losses in a window.
   Ideally, they may send L*W/2 packets in this stage, where L is the
   number of lost packets and W is the size of the congestion window
   where error occurs. Some recent work [REQTCP] on improving TCP
   performance allows transmitting packets even when receiving
   duplicate acknowledgments. Due to the above concerns, it'd better
   keep K large enough so as to prevent shrinking context window
   without enough confidence that corresponding packets had been
   successfully received.

   Considering the bandwidth-limited environments and the limited
   receiver buffer, a practical range of K is around 1~2. From the
   simulation results, K=1 is good enough for most cases.

5.9.4. Possible optimization in U-mode

   It can be seen that there are two distinct deployments - one where
   the forward and reverse paths share a link and one where they do not.

   In the former case it may be the situation that a compressor and
   decompressor could be co-located as illustrated in Figure 5.8.4. It
   may then be possible for the compressor and decompressor at each end
   of the link to exchange information. In such a scenario, ROHC-TCP
   can make further optimization on context size for windowed LSB
   encoding.


Zhang (ed.), et al.                                          [Page 31]

                       draft-ietf-rohc-tcp-02.txt


   In Figure 5.8.4., C-SN represents the compressor for the sequence
   number traffic that deployed in Host A, D-SN represents the
   decompressor for the sequence number traffic that deployed in Host B.
   Similarly, C-ACK represents the compressor for the acknowledgement
   number traffic that deployed in Host B, D-ACK represents the
   decompressor for the acknowledgement number traffic that deployed in
   Host A.

   Host A                                  Host B
   +------------------+               +------------------+
   |                  |               |                  |
   |   +---------+    |     SN     \  |    +---------+   |
   |   |  C-SN   |    |   ~  ~  ~  ~  |    |  D-SN   |   |
   |   +---------+    |            /  |    +---------+   |
   |       /|\        |               |                  |
   |        |         |               |                  |
   |   +---------+    |   /           |    +---------+   |
   |   |  D-ACK  |    |   ~  ~  ~  ~  |    |  C-ACK  |   |
   |   +---------+    |   \  ACK      |    +---------+   |
   |                  |               |                  |
   +------------------+               +------------------+

   Figure 5.8.4. Illustration of Possible optimization in U-mode.

   It is known that acknowledgement numbers (from C-ACK to D-ACK) are
   generally taken from the sequence numbers (from C-SN to D-SN) in the
   opposite direction. Since an acknowledgement cannot be generated for
   a packet that has not passed across the link, this offers an
   efficient way of estimating the TCP congestion window.

   Denote the current sequence number that is sending out from C-SN as
   SN-New, denote the sequence number that been acknowledged by the D-
   ACK as SN-Old, then the TCP congestion window (cwnd-bidir) can be
   represented as

           cwnd-bidir = SN-New - SN-Old.

   Having this new estimated congestion window, the control parameter W
   that is calculated in Section 5.2.1. will be re-calculated as

   W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack)
      = min ( W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack),
              cwnd-bidir)

6. Coding Scheme and compressed packet header format

   Following the requirement of TCP/IP header compression [REQTCP],
   ROHC-TCP should fit into the ROHC framework. Thus, ROHC-TCP will
   conform to the general format and the reserved packet types defined
   in [RFC3095].

   In this document, ROHC-TCP adopts EPIC-LITE as the coding framework.
   The detail of EPIC-LITE scheme had been discussed in [EPIC]. EPIC-

Zhang (ed.), et al.                                          [Page 32]

                       draft-ietf-rohc-tcp-02.txt


   LITE is used to generate new ROHC profiles. This scheme takes as its
   input a list of fields in the protocol stack to be compressed, and
   for each field a choice of one or more compression techniques. Using
   this input EPIC-LITE derives a set of compressed header formats that
   can be used to quickly and efficiently compress and decompress
   headers.

   A TCP/IP profile is proposed to describe the behaviors of each field
   in TCP/IP header.

6.1. Fixed-payload encoding

   For some applications, such as bulk data transferring, etc., the
   payload size of each packet is usually a constant value, e.g. 1460
   bytes. In such a case, the sequence number and acknowledgment number
   can be represented as the following equation:

             SEQ (or ACK) = m * PAYLOAD + n.

   If all the packets in context window have the same 'n', only 'm'
   need be transmitted to the decompressor. The decompressor can assign
   the value of PAYLOAD by the packet size of the reference packet.
   Then, the decompressor can obtain the sequence number or
   acknowledgment number after correctly decoding 'm', and use them as
   the reference values. This encoding method is called fixed-payload
   encoding.

6.2. ROHC Profile for compression of TCP/IP

   This session describes a ROHC profile for the compression of TCP/IP.

   < need to be further refine>

   Note that the probabilities listed for each encoding method are
   initial estimates only. These need to be refined with more accurate
   values from genuine TCP/IP streams.

   The profile for TCP/IP compression is given below:

   only uses the following toolbox methods:
   - STATIC-KNOWN
   - STATIC-UNKNOWN
   - STATIC
   - IRREGULAR
   - LSB
   - VALUE
   - C


   profile_identifier      0xFFFF
   max_formats             60
                           ; to be refined
   max_sets                48

Zhang (ed.), et al.                                          [Page 33]

                       draft-ietf-rohc-tcp-02.txt


   bit_alignment           8
   npatterns               224
   CO_packet               TCP-IP-CO
   IR_packet               TCP-IP-IR
   IR-DYN_packet           TCP-IP-DYN


   TCP-IP-CO       =    INFERRED-IP-CHECKSUM(IPv4-co-header)
                        TCP-co-header
                        msn-co
                        CRC(3,80%) | CRC(7,20%)

   ;
   ; since we want to have a MSN in some packets and not in others,
   ; there needs to be some way to indicate that there is a
   ; context value present.
   ;
   ; we need to agree on the degree of CRC protection that is
   ; appropriate for the various packets
   ;

   TCP-IP-IR       =    INFERRED-IP-CHECKSUM(IPv4-ir-header)
                        TCP-ir-header
                        msn-ir
                        CRC(8,100%)

   TCP-IP-DYN      =    INFERRED-IP-CHECKSUM(IPv4-dyn-header)
                        TCP-dyn-header
                        msn-dyn
                        CRC(8,100%)

   IPv4-co-header  =    version
                        header_len
                        tos-co
                        ecn
                        length
                        ip-id-co
                        rf_flag
                        df_flag-co
                        mf_flag
                        offset
                        ttl-co
                        protocol
                        ip_chksum
                        src_address-co
                        dst_address-co

   IPv4-ir-header  =    version
                        header_len
                        tos-dyn
                        ecn
                        length
                        ip-id-dyn

Zhang (ed.), et al.                                          [Page 34]

                       draft-ietf-rohc-tcp-02.txt


                        rf_flag
                        df_flag-dyn
                        mf_flag
                        offset
                        ttl-dyn
                        protocol
                        ip_chksum
                        src_address-ir
                        dst_address-ir

   IPv4-dyn-header =    version
                        header_len
                        tos-dyn
                        ecn
                        length
                        ip-id-dyn
                        rf_flag
                        df_flag-dyn
                        mf_flag
                        offset
                        ttl-dyn
                        protocol
                        ip_chksum
                        src_address-co
                        dst_address-co

   version         =    VALUE(4,4,100%)

   header_len      =    VALUE(4,5,100%)

   tos-co          =    STATIC(99%) | IRREGULAR(6,1%)

   tos-dyn         =    IRREGULAR(6,100%)

   ecn             =    STACK-TO-CONTROL(2)

   length          =    INFERRED-SIZE(16,128)

   ip-id-co        =    NBO(16) ; check byte-order

                        FORMAT(ip-id-seq-co, ip-id-rnd)

                        STATIC(100%) ; nbo flag

   ip-id-dyn       =    NBO(16) ; check byte-order

                        FORMAT(ip-id-seq-dyn, ip-id-rnd)
                        IRREGULAR(16,100%)

                        IRREGULAR(1,100%) ; nbo flag

   ip-id-seq-co    =    LSB(4,3,70%) | LSB(6,8,15%) |
                        LSB(8,8,15%) | IRREGULAR(16,30%)

Zhang (ed.), et al.                                          [Page 35]

                       draft-ietf-rohc-tcp-02.txt



   ip-id-rnd       =    IRREGULAR(16,100%)

   ip-id-seq-dyn   =    IRREGULAR(16,100%)

   ;
   ; ip-id-seq-co should be refined as follows:
   ;
   ; ip-id-seq-co  =     LSB(4,3,70%) | LSB(6,8,15%) |
   ;                     LSB(8,8,10%) | IRREGULAR(16,5%)
   ;

   rf_flag         =    STACK-TO-CONTROL(1)

   df_flag-co      =    STATIC(80%) | IRREGULAR(20%)

   df-flag-dyn     =    IRREGULAR(1,100%)

   mf_flag         =    VALUE(1,0,100%)

   offset          =    VALUE(13,0,100%)

   ttl-co          =    STATIC(99%) | IRREGULAR(8,1%)

   ttl-dyn         =    IRREGULAR(8,100%)

   protocol        =    VALUE(8,6,100%)
                            ; need to take account of extension
                            ; headers at some point
                            ;

   ip_chksum       =    VALUE(16,0,100%)

   src_address-co  =    STATIC(100%)

   src_address-ir  =    IRREGULAR(32,100%)

   dst_address-co  =    STATIC(100%)

   dst_address-ir  =    IRREGULAR(32,100%)

   TCP-header-co   =    source_port-co
                        dest_port-co
                        seqno
                        ackno
                        data_offset
                        flags-co
                        window-co
                        tcp_chksum
                        urg_ptr-co

   TCP-header-dyn  =    source_port-co
                        dest_port-co

Zhang (ed.), et al.                                          [Page 36]

                       draft-ietf-rohc-tcp-02.txt


                        seqno
                        ackno
                        data_offset
                        flags-dyn
                        window-dyn
                        tcp_chksum
                        urg_ptr-dyn

   TCP-header-ir   =    source_port-ir
                        dest_port-ir
                        seqno
                        ackno
                        data_offset
                        flags-dyn
                        window-dyn
                        tcp_chksum
                        urg_ptr-dyn

   source_port-co  =    STATIC(100%)

   source_port-ir  =    IRREGULAR(16,100%)

   dest_port-co    =    STATIC(100%)

   dest_port-ir    =    IRREGULAR(16,100%)

   seqno           =    STACK-TO-CONTROL(32)

   ackno           =    STACK-TO-CONTROL(32)

   ;
   ; the following encode-method, 'seqno-co' and 'ackno-co' should be
   ; refined or removed if 'seqno-and-ackno-coÆ is used.
   ;

   seqno-co        =    LSB(8,63,5%) | LSB(14,4096,80%) |
                        LSB(20,16384,10%) | IRREGULAR(32,5%)

   seqno-dyn       =    IRREGULAR(32,100%)

   ackno-co        =    LSB(8,0,10%) | LSB(14,0,80%) |
                        LSB(20,0,5%) | IRREGULAR(32,5%)

   ackno-dyn       =    IRREGULAR(32,100%)

   data_offset     =    STACK-TO-CONTTROL(4)

   window-co       =    STATIC(80%) | LSB(12,63,10%) |
                        IRREGULAR(16,10%)

   window-dyn      =    IRREGULAR(16,100%)

   tcp_chksum      =    IRREGULAR(16,100%)

Zhang (ed.), et al.                                          [Page 37]

                       draft-ietf-rohc-tcp-02.txt




   urg-ptr         =    STACK-TO-CONTROL(16)

   urg_ptr-co      =    STATIC(99%) | IRREGULAR(16,1%)

   urg_ptr-dyn     =    IRREGULAR(16,100%)

   flags-co        =    reserved-co
                        cwr
                        ece
                        urg
                        ack
                        psh
                        rst-syn-fin-co

   flags-dyn       =    reserved-dyn
                        IRREGULAR(2,100%)
                        urg
                        IRREGULAR(1,100%)
                        psh-dyn
                        rst-syn-fin-dyn

   get-rf          =    ROTATE(4,1)
                        STACK-FROM-CONTROL(1)

   reserved-co     =    get-rf
                        FORMAT(reserved-unused, reserved-used)
                        STATIC(100%) ; format selector

   reserved-dyn    =    get-rf
                        FORMAT(reserved-unused, reserved-used)
                        IRREGULAR(1,100%) ; format selector

   reserved-unused =    VALUE(5,0,100%)

   reserved-used   =    reserved-flag
                        reserved-flag
                        reserved-flag
                        reserved-flag
                        reserved-flag

   reserved-flag   =    IRREGULAR(1,100%)

   cwr-ece         =    STACK-TO-CONTROL(2)

   cwr             =    IRREGULAR(1,100%)

   ece             =    IRREGULAR(1,100%)

   urg             =    STACK-TO-CONTROL(1)

   ack-co          =    VALUE(1,1,99.9%) | VALUE(1,0,0.1%)

Zhang (ed.), et al.                                          [Page 38]

                       draft-ietf-rohc-tcp-02.txt



   ack-dyn         =    IRREGULAR(1,100%)

   psh-co          =    FORMAT(reg-psh-co, irreg-psh)
                        STATIC(100%) ; format selector

   psh-dyn         =    FORMAT(reg-psh-dyn, irreg-psh)
                        IRREGULAR(1,100%) ; format selector

   reg-psh-co      =    STATIC(90%) | N(IRREGULAR(1,9%) |
   IRREGULAR(1,9%)

   reg-psh-dyn     =    IRREGULAR(1,100%)

   irreg-psh       =    IRREGULAR(1,100%)

   rst-syn-fin-co  =    no-flag(98%) | rst-only(1%) | fin-only(1%)

   no-flag         =    VALUE(3,0x0,100%)

   rst-only        =    VALUE(3,0x4,100%)

   syn-only        =    VALUE(3,0x2,100%)

   fin-only        =    VALUE(3,0x1,100%)

   rst-syn-fin-dyn =    IRREGULAR(3,100%)

   ;
   ; Since some TCP options MUST NOT occur in non-SYN packets and the
   ; compressed packet is only used for non-SYN packets, several
   ; encode-method, such as 'sack-permitted', should be removed from
   ; encode-method 'tcp-options-co'. Also, TCP No-Operation options is
   ; omitted here. In summary, encode-method 'tcp-options-co' should be
   ; refined.
   ;

   tcp-options-co  =    ROTATE(3,1) ; get TCP data offset
                        LIST(4,1,32,-160,8,
                           U(OPTIONAL(tcp-sack-co)),
                           U(OPTIONAL(tcp-timestamp-co)),
                           U(OPTIONAL(tcp-mss)),
                           U(OPTIONAL(tcp-end)),
                           U(OPTIONAL(tcp-wscale)),
                           U(OPTIONAL(sack-permitted)),
                           U(OPTIONAL(tcp-generic-co)),
                           U(OPTIONAL(tcp-generic-co)),
                           5,8,2,0,3,4)

                        STATIC(100%) ; option order

                        STATIC(95%) | IRREGULAR(8,5%) ; option presence


Zhang (ed.), et al.                                          [Page 39]

                       draft-ietf-rohc-tcp-02.txt


   ;
   ; Encode-method 'tcp-options-dyn' should be refined as describe
   ; above.
   ;

   tcp-options-dyn =    ROTATE(3,1) ; get TCP data offset
                        LIST(4,1,32,-160,8,
                           U(OPTIONAL(tcp-sack-dyn)),
                           U(OPTIONAL(tcp-timestamp-dyn)),
                           U(OPTIONAL(tcp-mss)),
                           U(OPTIONAL(tcp-end)),
                           U(OPTIONAL(tcp-wscale)),
                           U(OPTIONAL(sack-permitted)),
                           U(OPTIONAL(tcp-generic-dyn)),
                           U(OPTIONAL(tcp-generic-dyn)),
                           5,8,2,0,3,4)

                        IRREGULAR(24,100%) ; option order

                        IRREGULAR(8,100%) ; option presence

   ;
   ; need further discussion
   ;

   tcp-sack-co    =     VALUE(8,5,100%) ; type

                        STACK-TO-CONTROL(8) ; length

                        LIST(8,1,8,-16,0,
                           OPTIONAL(sack-block-co),
                           OPTIONAL(sack-block-co),
                           OPTIONAL(sack-block-co),
                           OPTIONAL(sack-block-co))

                        STATIC(90%) | IRREGULAR(8,10%) ; order

                        sack-block-presence

   sack-block-presence = VALUE(1,1,100%)

                         VALUE(1,1,50%) | VALUE(1,0,50%)

                         VALUE(1,1,20%) | VALUE(1,0,80%)

                         VALUE(1,1,5%) | VALUE(1,0,95%)

   tcp-sack-dyn   =     VALUE(8,5,100%) ; type

                        STACK-TO-CONTROL(8) ; length

                        LIST(8,1,8,-16,0,
                           OPTIONAL(sack-block-dyn),

Zhang (ed.), et al.                                          [Page 40]

                       draft-ietf-rohc-tcp-02.txt


                           OPTIONAL(sack-block-dyn),
                           OPTIONAL(sack-block-dyn),
                           OPTIONAL(sack-block-dyn))

                        IRREGULAR(8,10%) ; order

                        sack-block-presence-dyn

   sack-block-presence-dyn = IRREGULAR(1,100%)

                             IRREGULAR(1,100%)

                             IRREGULAR(1,100%)

                             IRREGULAR(1,100%)

   sack-block-dyn  =    sack-element-dyn

                        sack-element-dyn

   sack-block-co   =    sack-element-co

                        sack-element-co

   sack-element-dyn =   INFERRED-OFFSET-LIST(32) ; offset from base

                        STACK-TO-CONTROL(32) ; preserve new base

                        IRREGULAR(32,100%)

   sack-element     =   INFERRED-OFFSET-LIST(32) ; offset from base

                        STACK-TO-CONTROL(32) ; preserve new base

                        STATIC(50%) | LSB(16,32768,30%) |
   LSB(24,1048576,20%)


   tcp-timestamp-co =   VALUE(8,8,100%)  ; type
                        VALUE(8,10,100%) ; length
                        ts-entry
                        ts-entry

   ts-entry-co      =   LSB(12,0,60%) | LSB(16,0,30%) |
   IRREGULAR(32,10%)

   ts-entry-dyn     =   IRREGULAR(32,100%)

   tcp-mss          =   VALUE(8,2,100%) ; type
                        VALUE(8,4,100%) ; length
                        IRREGULAR-PADDED(16,11,99%) | IRREGULAR(16,1%)

   tcp-end          =   VALUE(8,0,100%) ; type

Zhang (ed.), et al.                                          [Page 41]

                       draft-ietf-rohc-tcp-02.txt



   tcp-wscale       =   VALUE(8,3,100%) ; type
                        VALUE(8,3,100%) ; length
                        IRREGULAR-PADDED(8,4,100%) ; scale

   tcp-sack-permitted = VALUE(8,4,100%) ; type
                        VALUE(8,2,100%) ; length

   tcp-generic-co   =   STATIC(100%) ; type
                        STACK-TO-CONTROL(8) ; length
                        UNCOMPRESSED(8,1,8,-16) ; value

   tcp-generic-dyn  =   IRREGULAR(8,100%) ; type
                        STACK-TO-CONTROL(8) ; length
                        UNCOMPRESSED(8,1,8,-16) ; value

   get-seq-ack      =   ROTATE(2,1)

                        STACK-FROM-CONTROL(2) ; cwr/ece

                        ROTATE(4,1)

                        STACK-FROM-CONTROL(2) ; ecn

                        STACK-FROM-CONTROL(32) ; ack

                        STACK-FROM-CONTROL(32) ; seq


   seqno-and-ackno-co = FORMAT(bulk-data-co, bulk-ack-co, interactive-
   co)

                        STATIC(100%) ; format selector

   seqno-and-ackno-dyn = FORMAT(bulk-data-dyn, bulk-ack-dyn,
   interactive-dyn)

                         IRREGULAR(2,100%) ; format-selector

   bulk-data-co     =    data-seqno-co
                         data-ackno-co
                         ecn-co

   bulk-ack-co      =    ack-seqno-co
                         ack-ackno-co
                         ecn-co

   interactive-co   =    interact-seqno-co
                         interact-ackno-co
                         ecn-co

   bulk-data-dyn    =    seqno-dyn
                         ackno-dyn

Zhang (ed.), et al.                                          [Page 42]

                       draft-ietf-rohc-tcp-02.txt


                         ecn-dyn

   bulk-ack-dyn     =    seqno-dyn
                         ackno-dyn
                         ecn-dyn

   interactive-dyn  =    seqno-dyn
                         ackno-dyn
                         ecn-dyn

   ;
   ; To be refined.
   ;

   data-seqno-co    =    LSB(14,0,50%) | LSB(16,32768,30%) |
                         LSB(20,65536,20%)

   data-ackno-co    =    STATIC(50%) | LSB(10,0,30%) | LSB(16,0,20%)


   ecn-co           =    FORMAT(no-ecn-co, use-ecn-co)

   no-ecn-co        =    VALUE(2,0,100%)

                         VALUE(2,0,100%)

   use-ecn-co       =    IRREGULAR(4,100%)

   seqno-dyn        =    IRREGULAR(32,100%)

   ackno-dyn        =    IRREGULAR(32,100%)

   ecn-dyn          =    FORMAT(no-ecn-dyn, use-ecn-dyn)

                         IRREGULAR(1,100%) ; format selector

   no-ecn-dyn       =    VALUE(2,0,100%)

                         VALUE(2,0,100%)

   use-ecn-dyn      =    IRREGULAR(2,100%)

                         IRREGULAR(2,100%)

   ack-seqno-co     =    STATIC(50%) | LSB(10,0,30%) | LSB(16,0,20%)

   ack-ackno-co     =    LSB(14,0,50%) | LSB(16,0,30%) |
                         LSB(20,0,20%)

   interact-seqno-co =   LSB(10,256,35%) | LSB(14,2048,50%) |
   LSB(18,4096,15%)

   interact-ackno-co =   LSB(10,0,35%) | LSB(14,0,50%) | LSB(18,0,15%)

Zhang (ed.), et al.                                          [Page 43]

                       draft-ietf-rohc-tcp-02.txt



   msn-ir           = MSN-IRREGULAR(16,10%)

   msn-dyn          = MSN-LSB(3,0,90%) | MSN-LSB(7,0,9%) | MSN-
   IRREGULAR(16,1%)

   ;
   ; context-updating support
   ;
   ; The following is the profile for ROHC context-updating. To be
   ; refined.
   ;

   TCP-IP-UPDATE    = base-context-id
                      INFERRED-IP-CHECKSUM(IPv4-update-header)
                      TCP-update-header
                      msn-dyn
                      CRC(8,100%)

   Base-context-id  = VALUE(0,0,60%)    ; this context is updated from
                                        ; a context, base context, with
                                        ; the same CID, i.e. this
                                        ; context is updated from
                                        ; itself.
                      | IRREGULAR(N,40%) ; the context is updated from
                                        ; the base context with a
                                        ; different CID. N is the
                                        ; number of bits for a CID.
                    ; The compressor choose a CID as the base of the
                    ; new CID. The decompressor decompress the
                    ; base-context-id from TCP-IP-UPDATE and copy the
                    ; content of base context to the new context.

   IPv4-update-header    = version
                           Header_len
                           tos-update
                           ecn
                           length
                           ip-id-update
                           rf-flag
                           df-flag-dyn
                           mf-flag
                           offset
                           ttl-update
                           protocol
                           ip-chhsum
                           src-address-update
                           dst-address-update

   tos-update            = STATIC(99%) | IRREGULAR(6,1%)

   ip-id-update          = NBO(16)
                           FORMAT(ip-id-seq-update, ip-id-rnd-update)

Zhang (ed.), et al.                                          [Page 44]

                       draft-ietf-rohc-tcp-02.txt


                           STATIC(99%) | IRREGULAR(1,100%) ; nbo flag

   ip-id-seq-update      = LSB(4,3,70%) | LSB(6,8,15%)
                           | LSB(8,8,10%) | IRREGULAR(16,5%)

   ip-ip-rnd-update      = IRREGULAR(16,100%)

   ttl-update            = STATIC(90%) | IRREGULAR(8,10%)

   src-address-update    = STATIC(90%) | IRREGULAR(32,10%)

   dst-address-update    = STATIC(90%) | IRREGULAR(32,10%)


   TCP-header-update     = source-port-update
                           dest-port-update
                           seqno
                           ackno
                           data_offset
                           flags-dyn
                           window-update
                           tcp_chksum
                           urg_ptr-dyn

   source-port-update    = LSB(4,3,70%) | LSB(6,8,15%)
                           | LSB(8,8,10%) | IRREGULAR(16,5%)

   dest-port-update      = LSB(4,3,70%) | LSB(6,8,15%)
                           | LSB(8,8,10%) | IRREGULAR(16,5%)
                         ; DELTA encoding may be more efficient here.
                         ; However, the delta should be the difference
                         ; between the new port number and the port
                         ; number in the base context, instead of the
                         ; difference between packets.

   window-update         = STATIC(80%) | LSB(12,63,10%)
                           | IRREGULAR(16,100%)

   tcp-options-update    = ROTATE(3,1) ; get the data_offset
                           LIST(4,1,32,-160,8,
                              U(OPTIONAL(tcp-sack-dyn)),
                              U(OPTIONAL(tcp-timestamp-update)),
                              U(OPTIONAL(tcp-mss-update)),
                              U(OPTIONAL(tcp-end)),
                              U(OPTIONAL(tcp-wscale-update)),
                              U(OPTIONAL(sack-permitted-update)),
                              U(OPTIONAL(tcp-generic-dyn)),
                              U(OPTIONAL(tcp-generic-dyn)),
                              5,8,2,0,3,4)
                           STATIC(%90) | IRREGULAR(24,10%) ; order
                           STATIC(%90) | IRREGULAR(8,10%) ; presence

   tcp-timestamp-update  = VALUE(8,8,100%)

Zhang (ed.), et al.                                          [Page 45]

                       draft-ietf-rohc-tcp-02.txt


                           VALUE(8,10,100%)
                           ts-entry-update
                           ts-entry-update

   ts-entry-update       = LSB(12,0,60%) | LSB(16,0,30%)
                           | IRREGULAR(32,10%)

   tcp-mss-update        = VALUE(8,2,100%)
                           VALUE(8,4,100%)
                           STATIC(90%) | IRREGULAR-PADDED(16,11,9%)
                           | IRREGULAR(16,1%)

   tcp-wscale            = VALUE(8,3,100%)
                           VALUE(8,3,100%)
                           STATIC(90%) | IRREGULAR-PADDED(8,4,10%)

   sack-permitted-update = VALUE(8,4,100%)
                           VALUE(8,2,100%)


7. Security considerations

   ROHC-TCP is conformed to ROHC framework. Consequently the security
   considerations for ROHC-TCP match those of [RFC3095].


8. Acknowledgements

   Thanks to
          Carsten Bormann
          Mikael Degermark
          Robert Hancock
          Stephen McCann
          Paul Ollis
          Richard Price
          Abigail Surtees
          Ya-Qin Zhang
          Wenwu Zhu
   for valuable input.

   Header compression schemes from [VJHC, IPHC, RFC3095] have been
   important sources of ideas and knowledge. This document also
   benefited from discussion on the ROHC mailing list about some key
   issues.


9. References

   [RFC2026]  S. Bradner, "The Internet Standards Process -- Revision
       3", BCP 9, RFC 2026, October 1996.

   [VJHC]  V. Jacobson, "Compressing TCP/IP headers for low-speed
       serial links", RFC 1144, February 1990.

Zhang (ed.), et al.                                          [Page 46]

                       draft-ietf-rohc-tcp-02.txt



   [IPHC]  M. Degermark, B. Nordgren, and S. Pink, "IP Header
       Compression", RFC 2507, February 1999.

   [RFC2018]  M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP
      Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC2883]  S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, "An
       Extension to the Selective Acknowledgement (SACK) Option for TCP",
       RFC 2883, July 2000.

   [RFC1323]  V. Jacobson, R. Braden, and D. Borman, "TCP Extensions
       for High Performance", RFC 1323, May 1992.

   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.

   [E2E]  V. Jacobson, "Fast Retransmit", Message to the end2end-
       interest mailing list, April 1990.

   [Mobi96]  M. Degermark, M. Engan, B. Nordgren, and Stephen Pink,
       "Low-loss TCP/IP header compression for wireless networks", In
       the Proceedings of MobiCom, 1996.

   [RFC3095] Bormann (ed.), et al., "RObust Header Compression (ROHC)",
       RFC 3095, July 2001.

   [CAC] V. Jacobson, "Congestion avoidance and control", In ACM
       SIGCOMM '88, 1988.

   [RFC2581] M. Allman, V. Paxson, and W. R. Stevens, "TCP Congestion
       Control", RFC 2581, April 1999.

   [RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit
       Congestion Notification (ECN) to IP", RFC 2481, January 1999.

   [ECN] K. K. RamaKrishnan, Sally Floyd, D. Black, "The Addition of
       Explicit Congestion Notification (ECN) to IP", Internet Draft
       (work in progress), June, 2001. <draft-ietf-tsvwg-ecn-04.txt>

   [REQTCP] L-E. Jonsson, "Requirements for ROHC IP/TCP header
       compression", Internet Draft (work in progress), June 20, 2001.

   [LTX] M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's
      Loss Recovery Using Limited Transmit", Internet Draft (work in
      progress), August 2000. <draft-ietf-tsvwg-limited-xmit-00.txt>

   [RFC3096] M. Degermark, "Requirements for robust IP/UDP/RTP header
      compression", RFC 3096, July 2001.

   [INITWIN] M. Allman, S. Floyd, and C. Partridge, "Increasing TCP's
      Initial Window", Internet Draft (work in progress), May 2001.
      <draft-ietf-tsvwg-initwin-00.txt>

Zhang (ed.), et al.                                          [Page 47]

                       draft-ietf-rohc-tcp-02.txt



   [EPIC] Richard Price et al, "Framework for EPIC-LITE", <draft-ietf-
       rohc-epic-lite-00.txt>, Internet Draft (work in progress), Oct.
       2001.

   [RFC791]    Postel, J., "Internet Protocol", STD 5, September 1981.

   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7,
   DARPA, September 1981.

   [RFC1072]   Jacobson, V., and R. Braden, "TCP Extensions for Long-
   Delay Paths", LBL, ISI, October 1988.

   [RFC1146]   Zweig, J., and C. Partridge, "TCP Alternate Checksum
   Options", UIUC, BBN, March 1990.

   [RFC1644]   Braden, R. "T/TCP -- TCP Extensions for Transactions
   Functional Specification", ISI, July 1994.

   [RFC1693]   Connolly, T., et al, "An Extension to TCP : Partial
   Order Service", University of Delaware, November 1994.

   [RFC2001]   Stevens, W., TCP Slow Start, Congestion Avoidance,
   Fast Retransmit, and Fast Recovery Algorithms, NOAO, January 1997

   [RFC2018]   Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A.,
   TCP Selective Acknowledgement Options, April 1996.

   [RFC2026]   Bradner, S., "The Internet Standards Process - Revision
   3", October 1996

   [RFC2385]   Heffernan, A., "Protection of BGP Sessions via the TCP
   MD5 Signature Option", Cisco Systems, August 1998.

   [RFC2474]   Nichols, K., et al Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers, December
   1998

   [RFC 2508]   Casner, S., Jacobson, V., Compressing IP/UDP/RTP
   Headers for Low-Speed Serial Links, Cisco Systems, February 1999

   [RFC2509]   Engan, M., et al, IP Header Compression over PPP,
   February 1999

   [RFC2883]   Floyd, S., et al, An Extension to the Selective
   Acknowledgement (SACK) Option for TCP, July 2000

   [ECN-X]      Spring, N., Wetherall, D., Ely, D., Robust ECN
   Signaling with Nonces, draft-ietf-tsvwg-tcp-nonce-02.txt,
   University of Washington, October 2001.

   [IANA]       http://www.iana.org/assignments/tcp-parameters


Zhang (ed.), et al.                                          [Page 48]

                       draft-ietf-rohc-tcp-02.txt


   [RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
   to-end Performance Implications of Slow Links", BCP 48, RFC 3150,
   July 2001.

   [TCP-WIRELESS] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A.
   and F. Khafizov, "TCP over 2.5G and 3G Wireless Networks", draft-
   ietf-pilc-2.5g3g-07.txt (work in progress), February 2002.

   [EIFEL] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
   TCP", draft-ietf-tsvwg-tcp-eifel-alg-03.txt (work in progress),
   February 2002.

   [PILC-ASYM] Balakrishnan, , Padmanabhan, V., Fairhurst, G. and M.
   Sooriyabandara, "TCP Performance Implications of Network Path
   Asymmetry", draft-ietf-pilc-asym-07.txt (work in progress), November
   2001.

   [PILC-ARQ] G. Fairhurst, L. Wood, ôAdvice to link designers on link
   Automatic Repeat reQuest (ARQ)ö, draft-ietf-pilc-link-arq-issues-
   03.txt (work in progress), Feb. 2002.

10. Authors' addresses

   Qian Zhang            Tel: +86 10 62617711-3135
   Email:                qianz@microsoft.com

   HongBin Liao          Tel: +86 10 62617711-3156
   Email:                i-hbliao@microsoft.com

   Microsoft Research Asia
   Beijing Sigma Center
   No.49, Zhichun Road, Haidian District
   Beijing 100080, P.R.C.

   Mark A West          Tel: +44 1794 833311
   Email:               mark.a.west@roke.co.uk

   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Lars-Erik Jonsson  Tel: +46 920 20 21 07
   EMail: lars-erik.jonsson@ericsson.com

   Box 920
   Ericsson Erisoft AB
   SE-971 28 Lulea, Sweden



Zhang (ed.), et al.                                          [Page 49]

                       draft-ietf-rohc-tcp-02.txt


Appendix A - Detailed classification of header fields

   Header compression is possible thanks to the fact that most header
   fields do not vary randomly from packet to packet.  Many of the
   fields exhibit static behavior or change in a more or less
   predictable way.  When designing a header compression scheme, it is
   of fundamental importance to understand the behavior of the fields
   in detail.

   Since the IP header does exhibit some slightly different behavior
   from that previously presented in [RFC3095] for the RTP case, it is
   also included in this document.

   It is intentional that much of the classification text from [RFC3095]
   has been borrowed. This is for easier reading rather than inserting
   many references to that document.

   Again based on the format presented in [RFC3095] TCP/IP header
   fields are classified and analyzed in two steps. First, we have a
   general classification in Section A.1, where the fields are
   classified on the basis of stable knowledge and assumptions. The
   general classification does not take into account the change
   characteristics of changing fields because those will vary more or
   less depending on the implementation and on the application used. A
   less stable but more detailed analysis of the change characteristics
   is then done in Section A.4. Finally, Section A.5 summarizes this
   appendix with conclusions about how the various header fields should
   be handled by the header compression scheme to optimize compression
   and functionality.


A.1. General classification

   Definitions (and some text) copied from [RFC3095] Appendix A.
   Differences between IP field behavior between [RFC3095] (i.e.
   IP/UDP/RTP behavior for audio and video applications) and this
   document have been identified.

   At a general level, the header fields are separated into 5 classes:

   INFERRED     These fields contain values that can be inferred from
                other values, for example the size of the frame
                carrying the packet, and thus do not have to be handled
                at all by the compression scheme.

   STATIC       These fields are expected to be constant throughout the
                lifetime of the packet stream. Static information must
                in some way be communicated once.

   STATIC-DEF   STATIC fields whose values define a packet stream. They
                are in general handled as STATIC.

   STATIC-KNOWN These STATIC fields are expected to have well-known

Zhang (ed.), et al.                                          [Page 50]

                       draft-ietf-rohc-tcp-02.txt


                values and therefore do not need to be communicated at
                all.

   CHANGING     These fields are expected to vary in some way:
                randomly, within a limited value set or range, or in
                some other manner.

   In this section, each of the IP and TCP header fields is assigned to
   one of these classes. For all fields except those classified as
   CHANGING, the motives for the classification are also stated. In
   section A.2, CHANGING fields are further examined and classified on
   the basis of their expected change behavior.


A.1.1. IP header fields

A.1.1.1. IPv6 header fields

             +---------------------+-------------+----------------+
             |        Field        | Size (bits) |      Class     |
             +---------------------+-------------+----------------+
             | Version             |      4      |     STATIC     |
             | DSCP*               |      6      |    CHANGING    |
             | ECT flag*           |      1      |    CHANGING    |
             | CE flag*            |      1      |    CHANGING    |
             | Flow Label          |     20      |   STATIC-DEF   |
             | Payload Length      |     16      |    INFERRED    |
             | Next Header         |      8      |     STATIC     |
             | Hop Limit           |      8      |    CHANGING    |
             | Source Address      |    128      |   STATIC-DEF   |
             | Destination Address |    128      |   STATIC-DEF   |
             +---------------------+-------------+----------------+

   * differs from [RFC3095]

        Version

        The version field states which IP version is used. Packets with
        different values in this field must be handled by different IP
        stacks. All packets of a packet stream must therefore be of the
        same IP version. Accordingly, the field is classified as STATIC.

        Flow Label

        This field may be used to identify packets belonging to a
        specific packet stream. If not used, the value should be set to
        zero. Otherwise, all packets belonging to the same stream must
        have the same value in this field, it being one of the fields
        that define the stream. The field is therefore classified as
        STATIC-DEF.

        Payload Length


Zhang (ed.), et al.                                          [Page 51]

                       draft-ietf-rohc-tcp-02.txt


        Information about packet length (and, consequently, payload
        length) is expected to be provided by the link layer. The field
        is therefore classified as INFERRED.

        Next Header

        This field will usually have the same value in all packets of a
        packet stream. It encodes the type of the subsequent header.
        Only when extension headers are sometimes present and sometimes
        not, will the field change its value during the lifetime of the
        stream. The field is therefore classified as STATIC.

        The classification of STATIC is inherited from [RFC3095].
        However, it should be pointed out that the next header field is
        actually determined by the type of the following header.  Thus,
        it might be more appropriate to view this as an inference,
        although this depends upon the specific implementation of the
        compression scheme.

        Source and Destination addresses

        These fields are part of the definition of a stream and must
        thus be constant for all packets in the stream. The fields are
        therefore classified as STATIC-DEF.

        This might be considered as a slightly simplistic view.  However
        for now the IP addresses are associated with the transport layer
        connection.  More complex flow-separation could, of course, be
        considered.

   Total size of the fields in each class:

                         +--------------+--------------+
                         | Class        | Size (octets)|
                         +--------------+--------------+
                         | INFERRED     |       2      |
                         | STATIC       |      1.5     |
                         | STATIC-DEF   |     34.5     |
                         | STATIC-KNOWN |      0       |
                         | CHANGING     |       2      |
                         +--------------+--------------+


A.1.1.2. IPv4 header fields

              +---------------------+-------------+----------------+
              | Field               | Size (bits) |      Class     |
              +---------------------+-------------+----------------+
              | Version             |      4      |      STATIC    |
              | Header Length       |      4      |   STATIC-KNOWN |
              | DSCP*               |      6      |     CHANGING   |
              | ECT flag*           |      1      |     CHANGING   |
              | CE flag*            |      1      |     CHANGING   |

Zhang (ed.), et al.                                          [Page 52]

                       draft-ietf-rohc-tcp-02.txt


              | Packet Length       |     16      |     INFERRED   |
              | Identification      |     16      |     CHANGING   |
              | Reserved flag*      |      1      |     CHANGING   |
              | Don't Fragment flag*|      1      |     CHANGING   |
              | More Fragments flag |      1      |   STATIC-KNOWN |
              | Fragment Offset     |     13      |   STATIC-KNOWN |
              | Time To Live        |      8      |     CHANGING   |
              | Protocol            |      8      |      STATIC    |
              | Header Checksum     |     16      |     INFERRED   |
              | Source Address      |     32      |    STATIC-DEF  |
              | Destination Address |     32      |    STATIC-DEF  |
              +---------------------+-------------+----------------+

   * differs from [RFC3095]

        Version

        The version field states which IP version is used. Packets with
        different values in this field must be handled by different IP
        stacks. All packets of a packet stream must therefore be of the
        same IP version. Accordingly, the field is classified as STATIC.

        Header Length

        As long no options are present in the IP header, the header
        length is constant and well known. If there are options, the
        fields would be STATIC, but it is assumed here that there are no
        options. The field is therefore classified as STATIC-KNOWN.

        Packet Length

        Information about packet length is expected to be provided by
        the link layer. The field is therefore classified as INFERRED.

        Flags

        The Reserved flag must be set to zero, as defined in [RFC791].
        In [RFC3095] the field is therefore classified as STATIC-KNOWN.
        However, a number of recent proposals for extensions to TCP make
        use of some of the previously 'reserved' bits.  It is therefore
        clear that a 'reserved' bit cannot be taken to have a guaranteed
        zero value, but may change.  It is unclear exactly how reserved
        bits should be handled, given that the possible future uses
        cannot be predicted.  It appears unwise to select an encoding
        that would preclude the use of a compression profile for a
        future change in the use of reserved fields.  For this reason
        the alternative encoding of CHANGING is suggested.  It would
        also be possible to have more than one compression profile, in
        one of which this field was considered to be STATIC-KNOWN.

        The More Fragments (MF) flag is expected to be zero because
        fragmentation is generally not expected.  As discussed in the
        RTP case, only the first fragment will contain the transport

Zhang (ed.), et al.                                          [Page 53]

                       draft-ietf-rohc-tcp-02.txt


        layer protocol header; subsequent fragments would have to be
        compressed with a different profile.  In terms of the effect of
        header overhead, if fragmentation does occur then the first
        fragment, by definition, should be relatively large, minimizing
        the header overhead.  In the case of TCP, fragmentation should
        not be common due to a combination of initial MSS negotiation
        and subsequent use of path-MTU discovery. The More Fragments
        flag is therefore classified as STATIC-KNOWN.  However, a
        profile could accept that this flag may be set in order to cope
        with fragmentation.

        Fragment Offset

        Under the assumption that no fragmentation occurs, the fragment
        offset is always zero. The field is therefore classified as
        STATIC-KNOWN.  Even if fragmentation were to be further
        considered, then only the first fragment would contain the TCP
        header and would still be zero.

        Protocol

        This field will usually have the same value in all packets of a
        packet stream. It encodes the type of the subsequent header.
        Only when extension headers are sometimes present and sometimes
        not, will the field change its value during the lifetime of a
        stream. The field is therefore classified as STATIC.

        Header Checksum

        The header checksum protects individual hops from processing a
        corrupted header. When almost all IP header information is
        compressed away, there is no point in having this additional
        checksum; instead it can be regenerated at the decompressor side.
        The field is therefore classified as INFERRED.

        We note that the TCP checksum does not protect the whole TCP/IP
        header, but only the TCP pseudo-header (and the payload).
        Compare this with [RFC3095], which uses a CRC to verify the
        uncompressed header.  Given the need to validate the complete
        TCP/IP header; the cost of computing the TCP checksum over the
        entire payload; and known weaknesses in the TCP checksum, an
        additional check is necessary.  Therefore, it is expected than
        some additional checksum (such as a CRC) will be used to
        validate correct decompression.

        Source and Destination addresses

        These fields are part of the definition of a stream and must
        thus be constant for all packets in the stream. The fields are
        therefore classified as STATIC-DEF.

   Total size of the fields in each class:


Zhang (ed.), et al.                                          [Page 54]

                       draft-ietf-rohc-tcp-02.txt


                          +--------------+----------------+
                          | Class        | Size (octets)  |
                          +--------------+----------------+
                          | INFERRED     |        4       |
                          | STATIC*      |        1.5     |
                          | STATIC-DEF   |        8       |
                          | STATIC-KNOWN*|        2.25    |
                          | CHANGING*    |        4.25    |
                          +--------------+----------------+
   * differs from [RFC3095]


A.1.2. TCP header fields

             +---------------------+-------------+----------------+
             | Field               | Size (bits) |      Class     |
             +---------------------+-------------+----------------+
             | Source Port         |     16      |    STATIC-DEF  |
             | Destination Port    |     16      |    STATIC-DEF  |
             | Sequence Number     |     32      |     CHANGING   |
             | Acknowledgement Num |     32      |     CHANGING   |
             | Data Offset         |      4      |     INFERRED   |
             | Reserved            |      4      |     CHANGING   |
             | CWR flag            |      1      |     CHANGING   |
             | ECE flag            |      1      |     CHANGING   |
             | URG flag            |      1      |     CHANGING   |
             | ACK flag            |      1      |     CHANGING   |
             | PSH flag            |      1      |     CHANGING   |
             | RST flag            |      1      |     CHANGING   |
             | SYN flag            |      1      |     CHANGING   |
             | FIN flag            |      1      |     CHANGING   |
             | Window              |     16      |     CHANGING   |
             | Checksum            |     16      |     CHANGING   |
             | Urgent Pointer      |     16      |     CHANGING   |
             | Options             |   0(-352)   |     CHANGING   |
             +---------------------+-------------+----------------+

        Source and Destination ports

        These fields are part of the definition of a stream and must
        thus be constant for all packets in the stream. The fields are
        therefore classified as STATIC-DEF.

        Data Offset

        The number of 4 octet words in the TCP header, thus indicating
        The start of the data. It is always a multiple of 4 octets. It
        can be re-constructed from the length of any options and is not
        necessary to carry this explicitly. The field is therefore
        classified as INFERRED.


A.1.3. Summary for IP/TCP

Zhang (ed.), et al.                                          [Page 55]

                       draft-ietf-rohc-tcp-02.txt



   Summarizing this for IP/TCP one obtains

             +----------------+----------------+----------------+
             | Class \ IP ver | IPv6 (octets)  | IPv4 (octets)  |
             +----------------+----------------+----------------+
             | INFERRED       |   2 + 4 bits   |   4 + 4 bits   |
             | STATIC         |   1 + 4 bits   |   1 + 4 bits   |
             | STATIC-DEF     |  38 + 4 bits   |      12        |
             | STATIC-KNOWN   |       -        |   2 + 2 bits   |
             | CHANGING       |  17 + 4 bits   |  19 + 6 bits   |
             +----------------+----------------+----------------+
             | Totals         |     60         |     40         |
             +----------------+----------------+----------------+

        (excludes options, which are all classified as CHANGING)


A.2. Analysis of change patterns of header fields

   To design suitable mechanisms for efficient compression of all
   header fields, their change patterns must be analyzed. For this
   reason, an extended classification is done based on the general
   classification in Section A.1, considering the fields which were
   labeled CHANGING in that classification.

   The CHANGING fields are separated into five different subclasses:

   STATIC                These are fields that were classified as
                         CHANGING on a general basis, but are
                         classified as STATIC here due to certain
                         additional assumptions.

   SEMISTATIC            These fields are STATIC most of the time.
                         However, occasionally the value changes but
                         reverts to its original value after a known
                         number of packets.

   RARELY-CHANGING (RC)  These are fields that change their values
                         occasionally and then keep their new values.

   ALTERNATING           These fields alternate between a small number
                         of different values.

   IRREGULAR             These, finally, are the fields for which no
                         useful change pattern can be identified.

   To further expand the classification possibilities without
   increasing complexity, the classification can be done either
   according to the values of the field and/or according to the values
   of the deltas for the field.



Zhang (ed.), et al.                                          [Page 56]

                       draft-ietf-rohc-tcp-02.txt


   When the classification is done, other details are also stated
   regarding possible additional knowledge about the field values
   and/or field deltas, according to the classification. For fields
   classified as STATIC or SEMISTATIC, the case could be that the value
   of the field is not only STATIC but also well KNOWN a priori (two
   states for SEMISTATIC fields). For fields with non-irregular change
   behavior, it could be known that changes usually are within a
   LIMITED range compared to the maximal change for the field. For
   other fields, the values are completely UNKNOWN.

   Table 1 classifies all the CHANGING fields on the basis of their
   expected change patterns. (4) refers to IPv4 fields and (6) refers
   to IPv6.


   +------------------------+-------------+-------------+------------+
   | Field                  | Value/Delta |    Class    |  Knowledge |
   +========================+=============+=============+============+
   | IP TOS(4) / Tr.Class(6)| Value       |      RC     |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | IP ECT flag(4)         | Value       |      RC     |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | IP CE flag(4)          | Value       |      RC     |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   |            |Sequential | Delta       |    STATIC   |    KNOWN   |
   |            |-----------+-------------+-------------+------------+
   | IP Id(4)   | Seq. jump | Delta       |      RC     |   LIMITED  |
   |            |-----------+-------------+-------------+------------+
   |            |    Random | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | IP DF flag(4)          | Value       |      RC     |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | IP TTL(4) / Hop Lim(6) | Value       | ALTERNATING |   LIMITED  |
   +------------------------+-------------+-------------+------------+
   | TCP Sequence Number    | Delta       |  IRREGULAR  |   LIMITED  |
   +------------------------+-------------+-------------+------------+
   | TCP Acknowledgement Num| Delta       |  IRREGULAR  |   LIMITED  |
   +------------------------+-------------+-------------+------------+
   | TCP Reserved           | Value       |      RC     |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP ECN flags          | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP CWR flag           | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP ECE flag           | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP URG flag           | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP ACK flag           | Value       |  SEMISTATIC |   KNOWN    |
   +------------------------+-------------+-------------+------------+
   | TCP PSH flag           | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP RST flag           | Value       |  IRREGULAR  |   UNKNOWN  |

Zhang (ed.), et al.                                          [Page 57]

                       draft-ietf-rohc-tcp-02.txt


   +------------------------+-------------+-------------+------------+
   | TCP SYN flag           | Value       |  SEMISTATIC |   KNOWN    |
   +------------------------+-------------+-------------+------------+
   | TCP FIN flag           | Value       | SEMISTATIC  |   KNOWN    |
   +------------------------+-------------+-------------+------------+
   | TCP Window             | Value       | ALTERNATING |   KNOWN    |
   +------------------------+-------------+-------------+------------+
   | TCP Checksum           | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+
   | TCP Urgent Pointer     | Value       |  IRREGULAR  |   KNOWN    |
   +------------------------+-------------+-------------+------------+
   | TCP Options            | Value       |  IRREGULAR  |   UNKNOWN  |
   +------------------------+-------------+-------------+------------+

               Table 1 : Classification of CHANGING header fields

   The following subsections discuss the various header fields in
   detail. Note that table 1 and the discussions below do not consider
   changes caused by loss or reordering before the compression point.


A.2.1. IP header

A.2.1.1. IP Traffic-Class / Type-Of-Service (TOS)

   The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field might be
   expected to change during the lifetime of a packet stream.  This
   analysis considers several RFCs that describe modifications to the
   original [RFC791].

   The TOS byte was initially described in [RFC791] as 3 bits of
   precedence followed by 3 bits of TOS and 2 reserved bits (defined to
   be 0).  [RFC1122] extended this to specify 5 bits of TOS, although
   the meanings of the additional 2 bits were not defined.  [RFC1349]
   defined the 4th bit of TOS to be 'minimize monetary cost'.
   The next significant change was in [RFC2474] which reworked the TOS
   octet as 6 bits of DSCP (DiffServ Code Point) plus 2 unused bits.
   Most recently [RFC2780] identified the 2 reserved bits in the TOS or
   traffic class octet for experimental use with ECN.

   For the purposes of this classification, it is therefore proposed to
   classify the TOS (or traffic class) octet as 6 bits for the DSCP and
   2 additional bits.  This may be expected to be 0 or to contain ECN
   data.  From a future proofing perspective, it is preferable to
   assume the use of ECN, especially with respect to TCP.

   It is also considered important that the profile works with legacy
   stacks, since these will be in existence for some considerable time
   to come.  For simplicity, this will be considered as 6 bits of TOS
   information and 2 bits of ECN data, so the fields are always
   considered to be structured the same way.


Zhang (ed.), et al.                                          [Page 58]

                       draft-ietf-rohc-tcp-02.txt


   The DSCP (as for TOS in ROHC RTP) is not expected to change
   frequently.


A.2.1.2. ECN Flags

   Initially we describe the ECN flags as specified in [RFC2481].
   Subsequently, a suggested update is described which would alter the
   behavior of the flags.

   In [RFC2481] there are 2 separate flags, the ECT (ECN Capable
   Transport) flag and the CE (Congestion Experienced) flag.
   The ECT flag, if negotiated by the TCP stack, will be '1' for all
   data packets and '0' for all 'pure acknowledgement' packets.  This
   means that the behavior of the ECT flag is linked to behavior in the
   TCP stack.  Whether this can be exploited for compression is not
   clear.

   The CE flag is only used if ECT is set to '1' and indicates
   congestion in the network.  The CE flag is expected to be randomly
   (and comparatively rarely, although this is dependent upon the
   network congestion state) set to '1'.

   A recent draft [nonce] suggests an alternative view of these 2 bits.
   This considers the two bits together as having 4 possible
   codepoints.  Meanings are then assigned to the codepoints:

           00      Not ECN capable
           01      ECN capable, no congestion [known as ECT(0)]
           10      ECN capable, no congestion [known as ECT(1)]
           11      Congestion experienced

   The use of 2 codepoints for signaling ECT allows the sender to
   detect when a receiver is not reliably echoing congestion
   information.

   For the purposes of compression, this update means that ECT(0) and
   ECT(1) are equally likely (for an ECN capable flow) and that '11'
   will be relatively rarely seen. The probability of seeing a
   congestion indication depends upon the level of congestion in the
   network and this depends upon many factors.  However, it is likely
   that the probability is non-trivial and may, in many cases, be
   significant.


A.2.1.3. IP Identification

   The Identification field (IP ID) of the IPv4 header is there to
   identify which fragments constitute a datagram when reassembling
   fragmented datagrams. The IPv4 specification does not specify
   exactly how this field is to be assigned values, only that each
   packet should get an IP ID that is unique for the source-destination
   pair and protocol for the time the datagram (or any of its fragments)

Zhang (ed.), et al.                                          [Page 59]

                       draft-ietf-rohc-tcp-02.txt


   could be alive in the network. This means that assignment of IP ID
   values can be done in various ways, which we have separated into
   three classes:

        Sequential jump

        This is the most common assignment policy in today's IP stacks.
        A single IP ID counter is used for all packet streams. When the
        sender is running more than one packet stream simultaneously,
        the IP ID can increase by more than one between packets in a
        stream. The IP ID values will be much more predictable and
        require fewer bits to transfer than random values, and the
        packet-to-packet increment (determined by the number of active
        outgoing packet streams and sending frequencies) will usually be
        limited.

        Random

        Some IP stacks assign IP ID values using a pseudo-random number
        generator. There is thus no correlation between the ID values of
        subsequent datagrams. Therefore there is no way to predict the
        IP ID value for the next datagram. For header compression
        purposes, this means that the IP ID field needs to be sent
        uncompressed with each datagram, resulting in two extra octets
        of header. IP stacks in cellular terminals should not use this
        IP ID assignment policy.

        Sequential

        This assignment policy keeps a separate counter for each
        outgoing packet stream and thus the IP ID value will increment
        by one for each packet in the stream, except at wrap around.
        Therefore, the delta value of the field is constant and well
        known a priori. This assignment policy is the most desirable for
        header compression purposes. However, its usage is not as common
        as it perhaps should be.

   In order to avoid violating [IPv4], packets sharing the same IP
   address pair and IP protocol number cannot use the same IP ID values.
   Therefore, implementations of sequential policies must make the ID
   number spaces disjoint for packet streams of the same IP protocol
   going between the same pair of nodes. This can be done in a number
   of ways, all of which introduce occasional jumps, and thus makes the
   policy less than perfectly sequential. For header compression
   purposes less frequent jumps are preferred.

   It should be noted that the ID is an IPv4 mechanism and is therefore
   not a problem for IPv6. For IPv4 the ID could be handled in three
   different ways. First, we have the inefficient but reliable solution
   where the ID field is sent as-is in all packets, increasing the
   compressed headers by two octets. This is the best way to handle the
   ID field if the sender uses random assignment of the ID field.
   Second, there can be solutions with more flexible mechanisms

Zhang (ed.), et al.                                          [Page 60]

                       draft-ietf-rohc-tcp-02.txt


   requiring fewer bits for the ID handling as long as sequential jump
   assignment is used. Such solutions will probably require even more
   bits if random assignment is used by the sender. Knowledge about the
   sender's assignment policy could therefore be useful when choosing
   between the two solutions above. Finally, even for IPv4, header
   compression could be designed without any additional information for
   the ID field included in compressed headers. To use such schemes, it
   must be known which assignment policy for the ID field is being used
   by the sender. That might not be possible to know, which implies
   that the applicability of such solutions is very uncertain. However,
   designers of IPv4 stacks for cellular terminals should use an
   assignment policy close to sequential.

   With regard to TCP compression, the behavior of the IP ID field is
   considered to be essentially the same.  However, it is noted that
   the IP ID was generally inferred from the RTP Sequence Number.
   There is no obvious candidate in the TCP case for a field to offer
   this 'master sequence number' role.

   Clearly from a busy server the observed behavior may well be quite
   erratic.  This is a case where the ability to replicate the IP
   compression context between a number of flows (between the same end-
   points, or at least from the same server) would offer potential
   benefits.  However, this would only have any real impact where there
   were a large number of flows that can replicate their context based
   on each other.  The detail about the context replication can be
   found in Section A.3.


A.2.1.4. Don't Fragment (DF) flag

   Due to the use of path-MTU discovery [RFC1191], the value is more
   likely to be '1', than found in UDP/RTP streams since DF should be
   periodically set to check for fragmentation in the end-to-end path.
   In practice it is hard to predict the behavior of this field.
   However, it is considered that the most likely case is that it will
   generally stay at either '0' (periodically being set to '1') or '1'.


A.2.1.5. IP Hop-Limit / Time-To-Live (TTL)

   The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
   constant during the lifetime of a packet stream or to alternate
   between a limited number of values due to route changes.


A.2.2. TCP header

   Any discussion of compressibility of TCP fields borrows heavily from
   [VJHC].  However, the premise of how the compression is performed is
   slightly different and the protocol has evolved slightly in the
   intervening time.


Zhang (ed.), et al.                                          [Page 61]

                       draft-ietf-rohc-tcp-02.txt



A.2.2.1. Sequence number

   An understanding of the sequence and acknowledgement number behavior
   are essential for a TCP compression scheme.

   At the simplest level the behavior of the sequence number can be
   described relatively easily.  However, there are a number of
   complicating factors that also need to be considered.

   For transferring in-sequence data packets, the sequence number will
   increment for each packet by between 0 and an upper limit defined by
   the MSS (Maximum Segment Size).

   Although there are common MSS values, these can be quite variable.
   Given this variability and the range of window sizes it is hard
   (compared with the RTP case, for example) to select a 'one size fits
   all' encoding for the sequence number.  (The same argument applies
   equally to the acknowledgement number).

   We note that the increment of the sequence number in a packet is the
   size of the data payload of that packet (including the SYN and FIN
   flags; see later).  Meanwhile, at any point on the path (i.e.
   wherever a compressor might be deployed), the sequence number can be
   anywhere within a range defined by the TCP window.  This is a
   combination of a number of values (buffer space at the sender;
   advertised buffer size at the receiver; and TCP congestion control
   algorithms).  Missing packets or retransmissions can cause the TCP
   sequence number to fluctuate within the limits of this window.

   It would also be desirable to be able to predict the sequence number
   from some regularity.  However, this also appears to be difficult to
   do.  For example, during bulk data transfer the sequence number will
   tend to go up by 1 MSS per packet (assuming no packet loss).  Higher
   level values have been seen to have an impact as well, where
   sequence number behavior has been observed with an 8 kbyte repeating
   pattern - 5 segments of 1460 bytes followed by 1 segment of 892
   bytes.  It appears that implementation and how data is presented to
   the stack can affect the sequence number.

   It has been suggested that the TCP window can be tracked by the
   compressor, allowing it to bound the size of these jumps.

   For interactive flows (for example telnet), the sequence number will
   change by small irregular amounts.  In this case the Nagle algorithm
   commonly applies, coalescing small packets where possible to reduce
   the basic header overhead.  This may also mean that is less likely
   that predictable changes in the sequence number will occur.

   It is also noted that the SYN and FIN flags (which have to be
   acknowledged) consume 1 byte of sequence space.



Zhang (ed.), et al.                                          [Page 62]

                       draft-ietf-rohc-tcp-02.txt


A.2.2.2. Acknowledgement number

   Much of the information about the sequence number applies equally to
   the acknowledgement number.  However, there are some important
   differences.

   For bulk data transfers there will tend to be 1 acknowledgement for
   every 2 data segments.  It may be seen from this that the delta for
   the acknowledgement number is roughly twice that of the sequence
   number.  This is not always the case and the discussion about
   sequence number irregularity should be applied.

   Since the acknowledgement number is cumulative, dropped packets in
   the forward path will result in the acknowledgement number remaining
   constant for a time in the reverse direction.  Retransmission of a
   dropped segment can then cause a substantial jump in the
   acknowledgement number.  These jumps in acknowledgement number are
   bounded by the TCP window, just as for the jumps in sequence number.
   In the acknowledgement case, information about the advertised
   received window gives a bound to the size of any ACK jump.


A.2.2.3. Reserved

   This field is reserved and as such might be expected to be zero.
   This can no longer be assumed due to future proofing as it is only a
   matter of time before a suggestion for using the flag is made.


A.2.2.4. Flags

        ECN-E (Explicit Congestion Notification)
        '1' to echo CE bit in IP header.  Will be set in several
        consecutive headers (until 'acknowledged' by CWR)

        If ECN nonces get used, then there will be a 'nonce-sum' (NS)
        bit in the flags, as well.  Again, transparency of the reserved
        bits is crucial for future-proofing this compression scheme...
        From an efficiency/compression standpoint, the NS bit will
        either be unused [always 0] or randomly changing)

        CWR (Congestion Window Reduced)

        '1' to signal congestion window reduced on ECN. Will generally
        be set in individual packets.  Here, the probability of this
        flag being set is essentially equivalent to the probability of
        CE being signaled in the data-flow direction.  (This refers to
        CE being signaled somewhere in the end-to-end path; not
        necessarily prior to compression).

        ECE (Echo Congestion Experience)


Zhang (ed.), et al.                                          [Page 63]

                       draft-ietf-rohc-tcp-02.txt


        If 'congestion experienced' is signaled on a received IP header,
        this is echoed through the ECE bit in segments sent by the
        receiver until acknowledged by seeing the CWR bit set. Clearly
        in periods of high congestion and/or long RTT, this flag will be
        frequently set to '1'.

        During connection open (SYN and SYN/ACK packets) the ECN bits
        have special meaning:

        CWR + ECN-E are both set with SYN to indicate desire to use ECN
        CWR only is set in SYN-ACK to agree ECN
        (The difference in bit-patterns for the negotiation is so that
        it will work with broken stacks that reflect the value of
        reserved bits)

        URG (Urgent Flag)

        '1' to indicate urgent data [unlikely with any flag other than
        ACK]

        ACK (Acknowledgement)

        '1' for all except the initial 'SYN' packet

        PSH (Push Function Field)

        generally accepted to be randomly '0' or '1'. However, may be
        biased more to one value than the other (this is largely down to
        the implementation of the stack)

        RST (Reset Connection)

        '1' to reset a connection [unlikely with any flag other than ACK]

        SYN (Synchronize Sequence Number)

        '1' for the SYN/SYN-ACK only at the start of a connection

        FIN (End of Data : FINished)

        '1' to indicate 'no more data' [unlikely with any flag other
        than ACK]


A.2.2.5. Checksum

   Carried as the end-to-end check for the TCP data.  See [VJHC] for a
   discussion of why this should be carried.  There may be more complex
   interactions with error detection and robustness that would have to
   be addressed in a TCP header compression scheme.  The TCP checksum
   has to be considered as randomly changing.



Zhang (ed.), et al.                                          [Page 64]

                       draft-ietf-rohc-tcp-02.txt


A.2.2.6. Window

   May oscillate randomly between 0 and the receiver's window limit
   (for the connection).

   In practice, the window will either not change, or may alternate
   between a relatively small number of values.  Particularly when
   closing (the value is getting smaller), the change in window is
   likely to be related to the segment size, but it not clear that this
   necessarily offers any compression advantage.  When the window is
   opening, the effect of 'Silly-Window Syndrome' avoidance should be
   remembered.  This prevents the window opening by small amounts that
   would encourage the sender to clock out small segments.

   When thinking about what fields might change in a sequence of TCP
   segments, it should be noted that the receiver can generate 'window
   update' segments in which only the window advertisement changes.


A.2.2.7. Urgent pointer

   From a compression point of view, the Urgent Pointer is interesting
   because it offers an example where 'semantically identical'
   compression is not the same as 'bitwise identical'.  This is because
   the value of the Urgent Pointer is only valid if the URG flag is set.

   However, from the discussion of the TCP Checksum above, it should be
   realized that this enforces bitwise transparency of the scheme and
   so this argument is not particularly important.

   If the URG flag is set, then this pointer indicates the end of the
   urgent data and so can be point to anywhere in the window.  This may
   be set (and changing) over several segments.  Note that urgent data
   is rarely used, since it is not a particularly clean way of managing
   out-of-band data.


A.2.3. Options

   Options occupy space at the end of the TCP header. All options are
   included in the checksum. An option may begin on any byte boundary.
   The TCP header must be padded with zeros to make the header length a
   multiple of 32 bits.

   Optional header fields are identified by an option kind field.
   Options 0 and 1 are exactly one octet that is their kind field. All
   other options have their one octet kind field, followed by a one
   octet length field, followed by length-2 octets of option data.


A.2.3.1. Options overview


Zhang (ed.), et al.                                          [Page 65]

                       draft-ietf-rohc-tcp-02.txt


   Table 2 classifies the IANA known options together with their
   associated RFCs, if applicable [IANA].

   +------+--------+------------------------------------+-----------+
   | Kind | Length |               Meaning              |    RFC    |
   |      |(octets)|                                    |           |
   +------+--------+------------------------------------+-----------+
   |   0  |   -    | End of Option List                 | [RFC793]  |
   |   1  |   -    | No-Operation                       | [RFC793]  |
   |   2  |   4    | Maximum Segment Size               | [RFC793]  |
   |   3  |   3    | WSopt - Window Scale               | [RFC1323] |
   |   4  |   2    | SACK Permitted                     | [RFC2018] |
   |   5  |    N   | SACK                               | [RFC2018] |
   |   6  |    6   | Echo (obsoleted by option 8)       | [RFC1072] |
   |   7  |    6   | Echo Reply (obsoleted by option 8) | [RFC1072] |
   |   8  |   10   | TSopt - Time Stamp Option          | [RFC1323] |
   |   9  |    2   | Partial Order Connection Permitted | [RFC1693] |
   |  10  |    3   | Partial Order Service Profile      | [RFC1693] |
   |  11  |    6   | CC                                 | [RFC1644] |
   |  12  |    6   | CC.NEW                             | [RFC1644] |
   |  13  |    6   | CC.ECHO                            | [RFC1644] |
   |  14  |    3   | Alternate Checksum Request         | [RFC1146] |
   |  15  |    N   | Alternate Checksum Data            | [RFC1146] |
   |  16  |        | Skeeter                            |           |
   |  17  |        | Bubba                              |           |
   |  18  |    3   | Trailer Checksum Option            |           |
   |  19  |   18   | MD5 Signature Option               | [RFC2385] |
   |  20  |        | SCPS Capabilities                  |           |
   |  21  |        | Selective Negative Acknowledgements|           |
   |  22  |        | Record Boundaries                  |           |
   |  23  |        | Corruption experienced             |           |
   |  24  |        | SNAP                               |           |
   |  25  |        | Unassigned (released 12/18/00)     |           |
   |  26  |        | TCP Compression Filter             |           |
   +------+--------+------------------------------------+-----------+

                    Table 2 Description of common TCP options


A.2.3.2. Option field behavior

   Generally speaking all option fields have been classified as
   changing. This section describes the behavior of each option
   referenced within an RFC, listed by kind indicator.


   0. End of option list

       This option code indicates the end of the option list. This might
       not coincide with the end of the TCP header according to the Data
       Offset field. This is used at the end of all options, not the end
       of each option, and need only be used if the end of the options

Zhang (ed.), et al.                                          [Page 66]

                       draft-ietf-rohc-tcp-02.txt


       would not otherwise coincide with the end of the TCP header.
       [RFC793]

       There is no data associated with this option, a compression
       scheme must simply be able to encode its presence.


   1. No-Operation

       This option code may be used between options, for example, to
       align the beginning of a subsequent option on a word boundary.
       There is no guarantee that senders will use this option, so
       receivers must be prepared to process options even if they do not
       begin on a word boundary [RFC793].

       There is no data associated with this option, a compression
       scheme must simply be able to encode its presence.


   2. Maximum Segment Size

       If this option is present, then it communicates the maximum
       receive segment size at the TCP that sends this segment. This
       field must only be sent in the initial connection request (i.e.,
       in segments with the SYN control bit set). If this option is not
       used, any segment size is allowed [RFC793].

       This option is very common.  The segment size is a 16-bit
       quantity.  Theoretically this could take any value, however there
       are a number of values that are more common.  For example, 1460
       bytes are very common for TCP/IPv4 over Ethernet (though with the
       increased prevalence of tunnels, for example, smaller values such
       as 1400 have become more popular).  536 bytes is the default MSS
       value.  This may allow for common values to be encoded more
       efficiently.


   3. Window Scale Option (WSopt)

       This option may be sent in a SYN segment by TCP:

         (1)  to indicate that it is prepared to do both send and
         receive window scaling, and
         (2)  to communicate a scale factor to be applied to its receive
         window.

       The scale factor is encoded logarithmically, as a power of 2
       (presumably to be implemented by binary shifts).

       This option is sent only in a SYN segment (a segment with the SYN
       bit on), hence the window scale is fixed in each direction when a
       connection is opened.  A Window Scale option in a segment without a

Zhang (ed.), et al.                                          [Page 67]

                       draft-ietf-rohc-tcp-02.txt


       SYN bit should be ignored. The Window field in a SYN segment
       itself is never scaled [RFC1323]

       The use of window scaling does not affect the encoding of any
       other field during the life-time of the flow.  It is only the
       encoding of the window scaling option itself that is important.

       The window scale must be between 0 and 14 (inclusive).  Generally
       smaller values would be expected (a window scale of 14 allows for
       a 1Gbyte window, which is extremely large).


   4. SACK-Permitted

       This option may be sent in a SYN by a TCP that has been extended
       to receive (and presumably process) the SACK option once the
       connection has opened [RFC2018]. It MUST NOT be sent on non-SYN
       segments.

       There is no data in this option, all that is required is for the
       presence of the option to be encoded.


   5. SACK

       This option is to be used to convey extended acknowledgment
       information over an established connection. Specifically, it is
       to be sent by a data receiver to inform the data transmitter of
       non-contiguous blocks of data that have been received and queued.
       The data receiver is awaiting the receipt of data in later
       retransmissions to fill the gaps in sequence space between these
       blocks.

       At that time, the data receiver will acknowledge the data
       normally by advancing the left window edge in the Acknowledgment
       Number field of the TCP header. It is important to understand
       that the SACK option will not change the meaning of the
       Acknowledgment Number field, whose value will still specify the
       left window edge, i.e., one byte beyond the last sequence number
       of fully-received data [RFC2018].

       If SACK has been negotiated (through an exchange of SACK-
       Permitted options), then this option may occur when dropped
       segments are noticed by the receiver.  Because this identifies
       ranges of blocks within the receiver's window, this can be viewed
       as a base value with a number of offsets.  There can be up to 4
       SACK blocks in a single option.  SACK blocks may occur in a
       number of segments (if there is more out-of-order data 'on the
       wire') and this will typically extend the size of or add to the
       existing blocks.


Zhang (ed.), et al.                                          [Page 68]

                       draft-ietf-rohc-tcp-02.txt


       Alternative proposals such as DSACK [RFC2883] do not
       fundamentally change the behavior of the SACK block, from the
       point of view of the information contained within it.


   6. - 7.

       These options are generally not used in practice. It is obsoleted
       by the Timestamp option.  For transparency it is desirable that a
       compression scheme be able to encode it. However, there is no
       benefit in attempting any more sophisticated treatment than
       viewing it as a generic 'option').


   8. Timestamps

       This option carries two four-byte timestamp fields. The Timestamp
       Value field (TSval) contains the current value of the timestamp
       clock of the TCP sending the option. The Timestamp Echo Reply
       field (TSecr) is only valid if the ACK bit is set in the TCP
       header; if it is valid, it echoes a timestamp value that was sent
       by the remote TCP in the TSval field of a Timestamps option. When
       TSecr is not valid, its value must be zero. The TSecr value will
       generally be from the most recent Timestamp option that was
       received; however, there are exceptions that are explained below.
       A TCP may send the Timestamps option (TSopt) in an initial
       segment (i.e., segment containing a SYN bit and no ACK bit), and
       may send a TSopt in other segments only if it received a TSopt in
       the initial segment for the connection [RFC1323].

       Timestamps are quite commonly used.  If timestamp options are
       exchanged in the connection set-up phase, then they will appear
       on all subsequent segments.  If this exchange does not happen,
       then they will not appear for the remainder of the flow.

       Note that currently it is assumed that the negotiation of options
       such as timestamp occurs in the SYN packets.  However, should
       this ever be allowed to change (allowing timestamps to be enabled
       during an existing connection, for example), the presence of the
       option should still be handled correctly.

       Because the value being carried is a timestamp, it is logical to
       expect that the entire value need not be carried.  There is no
       obvious pattern of increments that might be expected, however.

       An important reason for using the timestamp option is to allow
       detection of sequence space wrap-around (Protection Against
       Wrapped Sequence-number, or PAWS [RFC1323]).  It is not expected
       that this is serious concern on the links that TCP header
       compression would be deployed on, but it is important that the
       integrity of this option is maintained.  This issue is discussed
       in, for example, [RFC3150].  However, the proposed Eifel
       algorithm [EIFEL] makes use of timestamps and so, currently, it

Zhang (ed.), et al.                                          [Page 69]

                       draft-ietf-rohc-tcp-02.txt


       is recommended that timestamps are used for cellular-type links
       [TCP-WIRELESS].

       The following layouts are recommended for sending options on non-
       SYN segments, to achieve maximum feasible alignment of 32-bit and
       64-bit machines.
              +--------+--------+--------+--------+
              |   NOP  |  NOP   |  TSopt |   10   |
              +--------+--------+--------+--------+
              |          TSval   timestamp        |
              +--------+--------+--------+--------+
              |          TSecr   timestamp        |
              +--------+--------+--------+--------+

       With regard to compression, it is further noted that the range of
       resolutions for the timestamp suggested in [RFC1323] is quite
       wide (1ms to 1s per 'tick').  This (along with the perhaps wide
       variation in RTT) makes it hard to select a set of encodings that
       will be optimal in all cases.


   9. - 15.

       Those options are in practice never seen, and so the only
       requirement is that the header compression scheme should be able
       to encode it.


   16. - 18.

       Are non-RFC references and are not considered in this document.


   19. MD5 Digest

       The primary motivation for this option is to allow BGP to protect
       itself against the introduction of spoofed TCP segments into the
       connection stream. Every segment sent on a TCP connection to be
       protected against spoofing will contain the 16-byte MD5 digest
       produced by applying the MD5 algorithm to a concatenated block of
       data.

       Unlike other TCP extensions (e.g., the Window Scale option
       [RFC1323]), the absence of the option in the SYN, ACK segment
       must not cause the sender to disable its sending of signatures.
       This negotiation is typically done to prevent some TCP
       implementations from misbehaving upon receiving options in non-
       SYN segments. This is not a problem for this option, since the
       SYN, ACK sent during connection negotiation will not be signed
       and will thus be ignored. The connection will never be made, and
       non-SYN segments with options will never be sent. More
       importantly, the sending of signatures must be under the complete

Zhang (ed.), et al.                                          [Page 70]

                       draft-ietf-rohc-tcp-02.txt


       control of the application, not at the mercy of the remote host
       not understanding the option.

       MD5 digest information should, like any cryptographically secure
       data, be incompressible.  Therefore the compression scheme must
       simply transparently carry this option, if it occurs.


   20. - 26.

       Are non-RFC references and are not considered in this document.


A.3. Some observations

A.3.1. Implicit acknowledgements

   There may be a small number of cues for 'implicit acknowledgements'
   in a TCP flow.  Even if the compressor only sees the data transfer
   direction, for example, then seeing a packet without the SYN flag
   set implies that the SYN packet has been received.

   It may be that there are other such cues that may be used in certain
   circumstances to improve compression efficiency.

A.3.2. Field dependence and packet behavior

   It should be apparent that direct comparisons with the highly
   'packet' based view of RTP compression are hard.  RTP header fields
   tend to change regularly per-packet and many fields (IPv4 IP ID, RTP
   sequence number and RTP timestamp, for example) typically change in
   a dependent, however, predictable manner.  However, TCP fields, such
   as sequence number tend to change more unpredictably, because of the
   influence of external factors (application behaviors, size of TCP
   windows, etc.).

   It's well-known that most TCP connections only have one-way traffic
   (for example, web browsing and FTP downloading).  That is, on the
   forward path (from server to client), only Sequence Number changes
   and Acknowledgement Number remains constant at most time; on the
   backward path (from client to server), only Acknowledgement Number
   changes and Sequence Number remain constant at most time.  Better
   knowledge of TCP packet behaviors will help the design of the packet
   format for compressed TCP header and achieve good tradeoff between
   complexity and efficiency.

A.3.3. Correlation and size constraint for TCP options

   It can be seen from the above analysis, most TCP options, such as
   MSS, WSopt, SACK-Permitted, may appear only on a SYN segment.
   Every implementation should (and we expect that most will) ignore
   unknown options on SYN segments.  TCP options will be sent on non-
   SYN segments only when an exchange of options on the SYN segments as

Zhang (ed.), et al.                                          [Page 71]

                       draft-ietf-rohc-tcp-02.txt


   indicated that both sides understand the extension.  Other TCP
   options, such as MD5 Digest, Timestamp also tend to be send when the
   connection initiated (with SYN packet).

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-byte words.  This means
   that the total size of the header plus option must be less than or
   equal to 60 bytes -- this leaves 40 bytes for options.


A.3.4. Short-lived flows

   It is hard to see what can be done to improve performance for a
   single, unpredictable, short-lived connection.  However, there are
   commonly cases where there will be multiple TCP connections between
   the same pair of hosts or at least send from the same source host.
   As a particular example, consider a mobile user browsing several web
   pages (this is more the case with HTTP/1.0 than HTTP/1.1) from the
   same web server.  Meanwhile, this mechanism can also be when all the
   connections have the same Source-IP.  In this case, multiple users
   in the same cell may browse different web pages from the same server.

   In those cases, multiple short-lived web flows are occurred
   simultaneously (or near simultaneously within a relatively short
   space of time).  Then, the IP header part of those contexts will
   probably be almost identical.  There are only small jump among the
   IP_IDs for those contexts.  Meanwhile, certain aspects of the TCP
   context may also be similar.  For example, it may be that one of the
   port numbers will stay the same (the service port) and the other
   will change by a small amount relative to the just-closed connection
   (the ephemeral port).

   Thus, support for sub-context sharing, or context replication
   (initializing one context from another) offers useful optimizations
   for a sequence of short-lived connections.

   It is noted that although TCP is connection oriented, it is hard to
   tell at a middle-box whether or not a TCP flow has finished.  For
   example, even in the 'bi-directional' link case, seeing a FIN and
   the ACK of the FIN at the compressor/decompressor does not mean that
   the FIN cannot be retransmitted.  In general, there are much more
   fields that are similar to the ones in other context than the
   exactly fixed/static ones.  Thus it may be more useful to think
   about using "context replication" to initialize a new context from
   an existing one, rather than re-using an existing one.

   A brief study on the TCP/IP field behavior among 'replicable' packet
   stream is given in the following.

   TERMS


Zhang (ed.), et al.                                          [Page 72]

                       draft-ietf-rohc-tcp-02.txt


   'Replicable' - Two packet streams are defined as replicable if they
                  belong to the same profile (ROHC/TCP, etc.) AND have
                  at least the identical Source IP address.

              -  The replicable property of a field specifies how
                  similar the value in a new context is to the existing
                  one.  It has the following values:

                  'N/A'  - The field is unnecessary to be replicated
                           since it can be inferred or used to define a
                           packet stream

                  'No'   - The field is impossible to be replicated
                           since its change pattern between two packet
                           streams are irregular

                  'Yes'  - The field is possible to be replicated.
                           Specific encoding method can be used to
                           improve the compression efficiency.


   IPv4 Header (inner and/or outer)

   Field                   Class           Replicable
   ------------------------------------------------
   Version                 STATIC          N/A
   Header Length           STATIC-KNOWN    Yes
   ToS                     CHANGING        Yes (1)
   Packet Length           INFERRED        N/A
   Identification          CHANGING        Yes (2)
   Reserved flag           STATIC-KNOWN    No  (3)
   Don't Fragment flag     STATIC          No
   More Fragments flag     STATIC-KNOWN    No
   Fragment Offset         STATIC-KNOWN    No
   Time To Live            CHANGING        Yes
   Protocol                STATIC          N/A
   Header Checksum         INFERRED        N/A
   Source Address          STATIC-DEF      N/A
   Destination Address     STATIC-DEF      N/A

   (1) ToS is marked based on the application's requirement.
   Considering that the replicable connections usually belong to same
   type of traffic, it can be regarded as replicable.

   (2) The replicable context for this field includes IP-ID, NBO, and
   RND flags.

   (3) Since the possible future behavior of the 'Reserved Flag' cannot
   be predicted, it is considered as not replicable.


   IPv6 Header (inner and/or outer)


Zhang (ed.), et al.                                          [Page 73]

                       draft-ietf-rohc-tcp-02.txt


   Field                   Class           Replicable
   ------------------------------------------------
   Version                 STATIC          N/A
   Traffic Class           CHANGING        No
   Flow Label              STATIC-DEF      N/A
   Payload Length          INFERRED        N/A
   Next Header             STATIC          N/A
   Hop Limit               CHANGING        Yes
   Source Address          STATIC-DEF      N/A
   Destination Address     STATIC-DEF      N/A


   TCP Header

   Field                   Class           Replicable
   ------------------------------------------------
   Source Port             STATIC-DEF      Yes (4)
   Destination Port        STATIC-DEF      Yes (4)
   Sequence Number         CHANGING        No  (5)
   Acknowledgement Number  CHANGING        No
   Data Offset             INFERRED        N/A
   Reserved Bits           CHANGING        Yes (6)
   Control Bits
           URG             CHANGING        No
           ACK             CHANGING        No
           PSH             CHANGING        No
           RST             CHANGING        No
           SYN             CHANGING        No
           FIN             CHANGING        No
   Window                  CHANGING        Yes (7)
   CHECKSUM                CHANGING        No
   Urgent Pointer          CHANGING        No

   (4) On the server side, the port number should be well-known value.
   On the client side, the port number is selected by OS automatically.
   Whether the port number is replicable depends on how the OS chooses
   port number.  However, most implementation uses a simple scheme
   which just search next available port number.

   (5) With the deployment of TCP Initial Sequence Number Randomization,
   the Sequence Number will be impossible to be replicated at all.
   Thus, this field will not be regarded as replicable.

   (6) Don't include ECN flags if ECT is enabled

   (7) The Window, here, should be referred as the initial value (or
   maximum value) of RWND. Since replicable packet streams are likely
   to have the same initial RWND, it would optimize the SYN packet size
   for short-lived TCP traffics.

   ECN Flags


Zhang (ed.), et al.                                          [Page 74]

                       draft-ietf-rohc-tcp-02.txt


   Field                   Class           Replicable
   ------------------------------------------------
   ECT                     CHANGING        No   (8)
   CE                      CHANGING        No
   ECN                     CHANGING        No
   CWR                     CHANGING        No

   (8) Considering that the IP ECN bits will also make use of the ECN
   nonce scheme.  None of the ECN flags could be regarded as replicable.


   TCP Options

   Option                         SYN-only (9)   Replicable
   -----------------------------------------------------
   End of option list Option      No             No
   No-Operation Option            No             No
   Maximum Segment Size Option    Yes            Yes
   Window Scale Option            Yes            Yes
   SACK-Permitted Option          Yes            Yes
   SACK Option                    No             No
   Timestamps Option              No             Yes

   (9) SYN-only indicates whether the options only appear in SYN packet
   or not. For 'Yes', the option only appears in SYN packet; otherwise,
   the option may appear in any packets.

   Most TCP options are used only in SYN packet. Some options, such as
   MSS, Window Scale, SACK-Permitted and etc., tend to have the same
   value among replicable packet streams. Since TCP options may not be
   included in the context if the header compression scheme doesn't
   support context replication. Thus, to support context replication,
   the compressor should maintain such TCP options in the context.


   The criterion to determine whether two contexts can be replicable is
   an implementation issue. For simplicity, contexts with the same
   Source-IP should be considered as replicable contexts, and only the
   most recent one should be used as the candidate to be replicated.

   To provide a simple and effective way to handle context replication
   issue, it is not necessary to handle the inter-profile replication.


A.3.5. Shared path

   At the risk of drifting into solution space, it can be seen that
   there are two distinct deployments - one where the forward and
   reverse paths share a link and one where they do not.

   In the former case it may be the case that a compressor and
   decompressor could be co-located.  It may then be possible for the

Zhang (ed.), et al.                                          [Page 75]

                       draft-ietf-rohc-tcp-02.txt


   compressor and decompressor at each end of the link to exchange
   information.  This could lead to possible optimizations.

   For example, acknowledgement numbers are generally taken from the
   sequence numbers in the opposite direction.  Since an
   acknowledgement cannot be generated for a packet that has not passed
   across the link, this offers an efficient way of encoding
   acknowledgements.































Zhang (ed.), et al.                                          [Page 76]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/