+---------------------+-------------+----------------+
| 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 |
+---------------------+-------------+----------------+
Figure 5: TCP header fields
o 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.
o Data Offset
The number of 4 octet words in the TCP header, 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 thus it is
not necessary to carry this explicitly. The field is therefore
classified as INFERRED.
2.3. Summary for IP/TCP
Summarizing this for IP/TCP, one obtains the following:
+----------------+----------------+----------------+
| 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).
Figure 6. Overall field sizes
3. Classification of Replicable Header Fields
Where multiple flows either overlap in time or occur sequentially
within a short space of time, there can be a great deal of similarity
in header field values. Such commonality of field values is
reflected in the compression context. Thus, it should be possible to
utilise commonality between fields across different flows to improve
the compression ratio. In order to do this, it is important to
understand the ’replicable’ characteristics of the various header
fields.
The key concept is that of ’replication’: an existing context is used
as a baseline and replicated to initialise a new context. Those
fields that are the same are then automatically initialised in the
new context. Those that have changed will be updated or overwritten
with values from the initialisation packet that triggered the
replication. This section considers the commonality between fields
in different flows.
Note, however, that replication is based on contexts (rather than on
just field values), so compressor-created fields that are part of the
context may also be included. These, of course, are dependent upon
the nature of the compression protocol (ROHC profile) being applied.
A brief analysis of the relationship of TCP/IP fields among
’replicable’ packet streams follows.
’N/A’: The field need not be considered in the replication
process, as it is inferred or known ’a priori’ (and,
therefore, does not appear in the context).
’No’: The field cannot be replicated since its change pattern
between two packet flows is uncorrelated.
’Yes’: The field may be replicated. This does not guarantee that
the field value will be the same across two candidate
streams, only that it might be possible to exploit
replication to increase the compression ratio. Specific
encoding methods can be used to improve the compression
efficiency.
3.1. IPv4 Header (Inner and/or Outer)
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Header Length | STATIC-KNOWN | N/A |
| DSCP | ALTERNATING | No (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Packet Length | INFERRED | N/A |
| Identification | CHANGING | Yes (3) |
| Reserved flag | CHANGING | No (4) |
| Don’t Fragment flag | CHANGING | Yes (5) |
| More Fragments flag | STATIC-KNOWN | N/A |
| Fragment Offset | STATIC-KNOWN | N/A |
| Time To Live | CHANGING | Yes |
| Protocol | STATIC | N/A |
| Header Checksum | INFERRED | N/A |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
Figure 7: IPv4 header
(1) The DSCP is marked according to the application’s requirements.
If it can be assumed that replicable connections belong to the
same diffserv class, then it is likely that the DSCP will be
replicable. The DSCP can be set not only by the sender but by
any packet marker. Thus, a flow may have a number of DSCP values
at different points in the network. However, header compression
operates on a point-to-point link and so would expect to see a
relatively stable value. If re-marking is being done based on
the state of a meter, then the value may change mid-flow.
Overall, though, we expect supporting replication of the DSCP to
be useful for header compression.
(2) It is not possible for the ECN bits to be replicated (note that
use of the ECN nonce scheme [19] is anticipated). However, it
seems likely that all TCP flows between ECN-capable hosts will
use ECN, the use (or not) of ECN for flows between the same end-
points might be considered replicable. See also note (4).
(3) The replicable context for this field includes the IP-ID, NBO,
and RND flags (as described in ROHC RTP). This highlights that
the replication is of the context, rather than just the header
field values and, as such, needs to be considered based on the
exact nature of compression applied to each field.
(4) Since the possible future behavior of the ’Reserved Flag’ cannot
be predicted, it is not considered as replicable. However, it
might be expected that the behavior of the reserved flag between
the same end-points will be similar. In this case, any selection
of packet formats (for example) based on this behavior might
carry across to the new flow. In the case of packet formats,
this can probably be considered as a compressor-local decision.
(5) In theory, the DF bit may be replicable. However, this is not
guaranteed and, in practice, it is unlikely to be useful to do
this. From the perspective of header compression, having to
indicate whether or not a 1-bit flag should be replicated or
specified explicitly is likely to require more bits than simply
conveying the value of the flag. We do not rule out DF
replication.
3.2. IPv6 Header (inner and/or outer)
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Version | STATIC | N/A |
| Traffic Class | CHANGING | Yes (1) |
| ECT flag | CHANGING | No (2) |
| CE flag | CHANGING | No (2) |
| Flow Label | STATIC-DEF | N/A |
| Payload Length | INFERRED | N/A |
| Next Header | STATIC | N/A |
| Hop Limit | CHANGING | Yes |
| Source Address | STATIC-DEF | Yes |
| Destination Address | STATIC-DEF | Yes |
+-----------------------+---------------+------------+
(1) See comment about DSCP field for IPv4, above.
(2) See comment about ECT and CE flags for IPv4, above.
Figure 8. IPv6 Header
3.3. TCP Header
+-----------------------+---------------+------------+
| Field | Class | Replicable |
+-----------------------+---------------+------------+
| Source Port | STATIC-DEF | Yes (1) |
| Destination Port | STATIC-DEF | Yes (1) |
| Sequence Number | CHANGING | No (2) |
| Acknowledgement Number| CHANGING | No |
| Data Offset | INFERRED | N/A |
| Reserved Bits | CHANGING | No (3) |
| Flags | | |
| CWR | CHANGING | No (4) |
| ECE | CHANGING | No (4) |
| URG | CHANGING | No |
| ACK | CHANGING | No |
| PSH | CHANGING | No |
| RST | CHANGING | No |
| SYN | CHANGING | No |
| FIN | CHANGING | No |
| Window | CHANGING | Yes |
| Checksum | CHANGING | No |
| Urgent Pointer | CHANGING | Yes (5) |
+-----------------------+---------------+------------+
Figure 9: TCP Header
(1) On the server side, the port number is likely to be a well-known
value. On the client side, the port number is generally selected
by the stack automatically. Whether the port number is
replicable depends upon how the stack chooses the port number.
Whilst most implementations use a simple scheme that sequentially
picks the next available port number, it may not be desirable to
rely on this behavior.
(2) With the recommendation (and expected deployment) of TCP Initial
Sequence Number randomization, defined in RFC 1948 [10], it will
be impossible to share the sequence number. Thus, this field
will not be regarded as replicable.
(3) See comment (4) for the IPv4 header, above.
(4) See comment (2) on ECN flags for the IPv4 header, above.
(5) The urgent pointer is very rarely used. This means that, in
practice, the field may be considered replicable.
3.4. TCP Options
+---------------------------+--------------+------------+
| Option | SYN-only (1) | Replicable |
+---------------------------+--------------+------------+
| End of Option List | No | No (2) |
| No-Operation | No | No (2) |
| Maximum Segment Size | Yes | Yes |
| Window Scale | Yes | Yes |
| SACK-Permitted | Yes | Yes |
| SACK | No | No |
| Timestamp | No | No |
+---------------------------+--------------+------------+
Figure 10. TCP Options
(1) This indicates whether the option only appears in SYN packets.
Options that are not ’SYN-only’ may appear in any packet. Many
TCP options are used only in SYN packets. Some options, such as
MSS, Window Scale, and SACK-Permitted, will tend to have the same
value among replicable packet streams.
Thus, to support context sharing, the compressor should maintain
such TCP options in the context (even though they only appear in
the SYN segment).
(2) Since these options have fixed values, they could be regarded as
replicable. However, the only interesting thing to convey about
these options is their presence. If it is known that such an
option exists, its value is defined.
3.5. Summary of Replication
From the above analysis, it can be seen that there are reasonable
grounds for exploiting redundancy between flows as well as between
packets within a flow. Simply consider the advantage of being able
to elide the source and destination addresses for a repeated
connection between two IPv6 endpoints. There will also be a cost (in
terms of complexity and robustness) for replicating contexts, and
this must be considered when one decides what constitutes an
appropriate solution.
Finally, note that the use of replication requires that the
compressor have a suitable degree of confidence that the source data
is present and correct at the decompressor. This may place some
restrictions on which of the ’changing’ fields, in particular, can be
utilised during replication.
4. 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 2, considering the fields that were labeled CHANGING in that
classification.
The CHANGING fields are separated into five different subclasses:
o STATIC
These are fields that were classified as CHANGING on a general
basis, but that are classified as STATIC here due to certain
additional assumptions.
o 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.
o RARELY-CHANGING (RC)
These are fields that change their values occasionally and then
keep their new values.
o ALTERNATING
These fields alternate between a small number of different values.
o 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.
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 value of the field could be 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 are usually within a LIMITED range compared to the
maximal change for the field. For other fields, the values are
completely UNKNOWN.
Figure 11 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 |
+========================+=============+=============+=============+
| DSCP(4) / Tr.Class(6) | Value | ALTERNATING | 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 flags | | | |